MinGW32 error when compiling trunk

[martinrame]

Hi, I did a "git clone git://git.dcmtk.org/dcmtk.git" then ./configure --without-libiconv && make all

Just after configuring, the make process started, and stopped with this:

Code: Select all

        -I/usr/local/include -O  -D_REENTRANT -D_XOPEN_SOURCE_EXTENDED -D_XOPEN_SOURCE=500 -D_BSD_SOURCE -D_BSD_COMPAT -D_OSF_SOURCE -D_POSIX_C_SOURCE=199506L -I/usr/local/include -mms-bitfields oflist.cc
In file included from oflist.cc:38:0:
../include/dcmtk/ofstd/oflist.h:54:2: error: #error Your C++ compiler cannot handle class templates:
In file included from oflist.cc:38:0:
../include/dcmtk/ofstd/oflist.h:522:2: error: #error Your C++ Compiler is not capable of compiling this code
../include/dcmtk/ofstd/oflist.h: En el constructor 'OFListLinkBase::OFListLinkBase()':
../include/dcmtk/ofstd/oflist.h:107:28: error: 'NULL' no se declaró en este ámbito
../include/dcmtk/ofstd/oflist.h: En el ámbito global:
../include/dcmtk/ofstd/oflist.h:123:5: error: 'size_t' no nombra a un tipo
../include/dcmtk/ofstd/oflist.h:131:5: error: 'size_t' no nombra a un tipo
../include/dcmtk/ofstd/oflist.h: En el constructor 'OFIterator<T>::OFIterator()':

I can compile 3.6.1 latest snapshot without problems, as well as 3.6.0.

[Uli Schlachter]

Where does this -mms-bitfields flag come from? That's nothing that DCMTK would do by itself. Also, could you upload your config.log somewhere? I'd like to know why exactly the 'checking for C++ class template' failed.

[martinrame]

Hi Uli, I don't know where the -mms-bitfields flag comes from too, as I explained in my initial post, this is a new clone from git, in an empty directory. I also tested it on a new PC, installing MinGW/MSys from scratch and got the same results.

I uploaded the config.log file to this place http://190.16.13.234/img/config.log

[Uli Schlachter]

According to that config.log, this error does not happen. Do you perhaps have an older DCMTK version installed to /usr/ or /usr/local/?

[martinrame]

Uli, thanks for your answer, regarding the error, it happens after "make clean all", that's why the configure.log doesn't show any error.

I don't have an older version installed.

[Uli Schlachter]

"make clean" does not affect config.log. This file is generated by configure and not modified afterwards (but "make distclean" deletes it).

This file basically contains a more verbose version of configure's output. So from your error message (e.g. "Your C++ compiler cannot handle class templates"), I learn that the test for this failed and thus HAVE_CLASS_TEMPLATE is not defined. However, your config.log says that this test succeeded. This must mean that the compiler doesn't find the correct config/include/dcmtk/config/osconfig.h. However, since you didn't get any error messages saying that this file wasn't found, I was thinking that it might have taken another osconfig.h from e.g. /usr/include/ or /usr/local/include.

So, could you run "locate osconfig.h" or "find / -name osconfig.h" just to make sure there really is no older DCMTK version laying around. Also, could you run "grep HAVE_CLASS_TEMPLATE config/include/dcmtk/config/osconfig.h" in DCMTK's source dir. This should find "#define HAVE_CLASS_TEMPLATE 1".

[martinrame]

Hi Uli, I did what you suggested and can't find another osconfig.h, then I did a "make distclean", and the grep you mentioned, but found "#undef HAVE_CLASS_TEMPLATE".

Please let me know if you need more info.

[Uli Schlachter]

But your config.log says the test succeeded and it contains "| #define HAVE_CLASS_TEMPLATE 1" a couple of times.

Does this config.log really belong to the osconfig.h that you are looking at? This doesn't make sense to me.

[martinrame]

Uli, I updated the config.log with the last ./configure I made, after make distclean.

Could you check it again?.

Thanks in advance.

[Uli Schlachter]

Code: Select all

$ grep HAVE_CLASS_TEMPLATE config.log | uniq
| #define HAVE_CLASS_TEMPLATE 1
#define HAVE_CLASS_TEMPLATE 1

That still looks like the last config.log that I saw. This all makes no sense.

[martinrame]

After some time, I wanted to try compiling from trunk again, also using MinGW/MSys, and got the same results

P.S.: I must point out that compiling from the latest snapshot works ok, the problem is when compiling from trunk.