STR #2651: Building errors under latest MingW/MSYS

STR #2651

Application:	FLTK Library
Status:	1 - Closed w/Resolution
Priority:	2 - Low, e.g. a documentation error or undocumented side-effect
Scope:	2 - Specific to an operating system
Subsystem:	Build Files
Summary:	Building errors under latest MingW/MSYS
Version:	1.3-current
Created By:	rokan
Assigned To:	AlbrechtS
Fix Version:	1.3.0 (SVN: v8797)
Update Notification:	Receive EMails Don't Receive EMails

Trouble Report Files:

#1	AlbrechtS 12:59 Jun 08, 2011

strtoll.tgz
70k

Trouble Report Comments:

#1	rokan 18:22 May 30, 2011

When building 1.3.0 with latest official MingW/Msys (32 bit version), build under 32 bit Win7; afrer ./autoconf, ./configure --enable-debug I get following errors: In file included from c:\mingw\bin\../lib/gcc/mingw32/4.5.2/../../../../include/objbase.h:12:0, from c:\mingw\bin\../lib/gcc/mingw32/4.5.2/../../../../include/ole2.h:9, from c:\mingw\bin\../lib/gcc/mingw32/4.5.2/../../../../include/windows.h:114, from c:\mingw\bin\../lib/gcc/mingw32/4.5.2/../../../../include/winsock2.h:22, from Fl.cxx:54: c:\mingw\bin\../lib/gcc/mingw32/4.5.2/../../../../include/stdlib.h:521:36: error: 'long long int strtol' redeclared as different kind of symbol c:\mingw\bin\../lib/gcc/mingw32/4.5.2/../../../../include/stdlib.h:329:38: error: previous declaration of 'long int strtol(const char*, char**, int)' c:\mingw\bin\../lib/gcc/mingw32/4.5.2/../../../../include/stdlib.h:521:36: error: expected primary-expression before 'const' c:\mingw\bin\../lib/gcc/mingw32/4.5.2/../../../../include/stdlib.h:521:36: error: expected ')' before 'const' make[1]: *** [Fl.o] Error 1 make: *** [all] Error 1

#2	AlbrechtS 01:35 May 31, 2011

That does not happen here with latest MinGW(32) on Win 7 *64-bit*. Maybe a 32-/64-bit issue (long long int vs. long int). Used here: gcc 4.5.2, w32api-3.17-2, ld (GNU Binutils) 2.21.

#3	AlbrechtS 01:41 May 31, 2011

Roman, you wrote that you configured with --enable-debug. Does it change it you don't use --enable-debug ? What are your exact gcc/ld/w32api versions?

#4	rokan 09:52 May 31, 2011

I have exactly the same configuration as yours (that is gcc 4.5.2, binutils 2.23 and Win32-API 3.17), tested without --enable-debug and also on "pure" 32 bit WinXP machine, the same result/errors. Ok, I think the problem is that I am using svn version of fltk-1.3 which does not include configure script - so I generate one using autoconf (with -f to be sure) bundled with mingw (2.67 btw). With the "configure" replaced by one from 1.3 snapshot everything works fine. I presume this version is generated on a *nix machine and for some reason the output is very different (bundled "configure" is 401 kb, mingw autoconf generates only 261 KB in size) - which is weird because I thought that result of autoconf should not depend on the target machine. Maybe mingw version of autoconf is broken? Maybe there is something wrong with configure.in and different autoconf versions handle it differently? Maybe "configure" script should be a part of the svn as well to avoid troubles/confusion by the users working with svn directly? In such a case you might consider to close/downgrade priority of this STR :-)

#5	AlbrechtS 10:43 Jun 01, 2011

I still can't replicate the problem. My MinGW version(s) on both Win7 (64-bit) and WinXP (32-bit) both work w/o problems. autoconf --version shows 2.67, and my configure script made by MinGW autoconf 2.67 is 261 KB, same as yours. I can also see that configure from RC5 (not RC6) is 401 KB (autoconf 2.61), and I built one myself on Linux with autoconf 2.63 (412 KB). This explains the different sizes you saw, but not the {bad|wrong} behavior. Roman, which autoconf version does your MinGW installation have? I'm also using the svn version with MinGW, so that I run autoconf myself, and I did never see any problems. The subversion repository does not have the configure script intentionally and I don't think that this is going to be changed. I lowered the priority and I think that this bug report should not stop RC7, but I'm not sure if there is a bug or not somewhere.

#6	AlbrechtS 10:45 Jun 01, 2011

Oh, sorry, I just saw that you wrote that you have autoconf 2.67.

#7	rokan 10:58 Jun 01, 2011

Hmm... My test was also with fresh install of mingw and fresh fltk-1.3 so I do not think I am messing up eg include directories. Do you want me to send the configure script (which makes errors) to compare with yours? You are right that it should not stop RC - they are comprising the script anyway...

#8	AlbrechtS 16:50 Jun 01, 2011

Looking at your posted error message: it says that strtol is defined twice in the same file, effectively: c:\mingw\include/stdlib.h:521:36: error: conflicting types for 'strtol' c:\mingw\include/stdlib.h:329:38: note: previous declaration of 'strtol' was here I have: $ grep -n strtol /mingw/include/*.h /mingw/include/stdlib.h:324:long double __cdecl __MINGW_NOTHROW strtold (const char * __restrict__, char ** __restrict__); /mingw/include/stdlib.h:329:_CRTIMP long __cdecl __MINGW_NOTHROW strtol (const char*, char**, int); /mingw/include/stdlib.h:521:long long __cdecl __MINGW_NOTHROW strtoll (const char* __restrict__, char** __restrict, int); /mingw/include/tchar.h:330:#define _tcstol strtol In line #521, I see "strtoll" and NOT "strtol" ! --- Now, for testing only, I edited line #521 to read "strtol", and I got the same message you got, but I got it for jpeg/jaricom.c since I am also compiling the bundled image libs. This means that either your stdlib.h file is broken, or you must have a strange "#define strtoll strtol" or something similar somewhere. Can you confirm this? I still don't know why it works with one or the other configure file, though ... (I don't think that posting the configure file might help much, since I never tried to read or understand a configure file, but if someone else wants to try it?)

#9	matt 12:37 Jun 03, 2011

Fixed in Subversion repository. I am not sure if I like to see the pattern, but for the sake of compatibility... . Anyway, fixed. Thanks, Manolo!

#10	matt 12:44 Jun 03, 2011

Sorry, wrong text for the wrong bug ;-)

#11	matt 12:53 Jun 03, 2011

Original poster: please verify that you compiler and header files were not modified. If I don't hear from you by Sunday noon CET, I will close this bug. Thanks.

#12	rokan 12:16 Jun 05, 2011

No, no headers were modified, the problem seems that the configure script seems not to find all the headers. When running this generated ./configure under the shell, it creates config.h with #undef HAVE_STRTOLL #ifndef HAVE_STRTOLL # define strtoll(nptr,endptr,base) strtol((nptr), (endptr), (base)) #endif /* !HAVE_STRTOLL */ and this new strtoll macro causes the conflit. The good old bundled configure script creates (under the same system, the same machine) #define HAVE_STRTOLL 1 #ifndef HAVE_STRTOLL # define strtoll(nptr,endptr,base) strtol((nptr), (endptr), (base)) #endif /* !HAVE_STRTOLL */ so it finds strtoll correctly and does not tries to do its own definition. I have tried to "mount" mingw directory under various standard folders (eg /usr/local/) so that configure can search at standard locations, nothing seems to help... I do not have cygwin installed either so there is no possibility of mismatch with it. Mingw installed under c:\MinGW, msys under c:\MinGW\msys\1.0 (new standard location)

#13	matt 07:16 Jun 08, 2011

You write that "The good old bundled configure script creates" a correct configuration. I don't understand that. Which one is the "good old" script, and which one are you using? The configure script uses AC_CHECK_FUNC(strtoll, AC_DEFINE(HAVE_STRTOLL)) which is the standard way to check for the existence of functions. I really would not know what to change here?! If this problem persists even after "make distclean", you'd probably have to contact the MINGW people.

#14	AlbrechtS 09:10 Jun 08, 2011

@Matt: Roman wrote that the "bundled" configure script in 1.3.0-rc6 worked, whereas the configure script created by himself (with MinGW's autoconf) doesn't - see also the different sizes and autoconf versions mentioned previously.

#15	rokan 09:13 Jun 08, 2011

The "good" script is one bundled in snapshots, the "bad" is the one which is generated by mingw autoconf. You are right that it seems rather bug of mingw autoconf. What puzzles me is this huge disparity between this stock configure script (401 kB) and this generated under mingw (261 kB). I thought that autoconf is completely system agnostic (that is the resulting configure script is always the same no mater where you are running autoconf on). However it is not so because I have just tested the same input under linux it generates "401 kB" configure, which then - when transported to mingw - runs just fine. You can probably close this STR if you think so, it does not seem to relate to fltk any more (unless there is something non-standard in fltk's configure.in).

#16	AlbrechtS 09:16 Jun 08, 2011

@Roman: okay, one last try from my side: I'd like to know why it doesn't work in your configuration. Could you please take a look at the file "config.log" after running the (MinGW-created) configure? I manipulated my configure.in to look for strtoxx instead of strtoll, and I see: configure:5886: checking for strtoxx configure:5886: gcc -o conftest.exe conftest.c >&5 C:\...\Temp\ccQA1oZB.o:conftest.c:(.text+0xc): undefined reference to `strtoxx' collect2: ld returned 1 exit status configure:5886: $? = 1 configure: failed program was: | /* confdefs.h */ ... So what I get is a linker error (undefined reference). What is your error message?

#17	AlbrechtS 09:27 Jun 08, 2011

Other than that I tend to remove the check for strtoll entirely from configure.in (and configh.in and all the other relevant files: CMake, IDE's etc.), because I can't find any reference of strtoll() in the FLTK code. Is it only me, or do we really not use it? Unfortunately there are a few files to change... OTOH I can't imagine that FLTK would have a need to use strtoll() now or in the future. What would it be good for? ...

#18	rokan 10:02 Jun 08, 2011

well, the "bad script" generates this within config.log: From line 1068: configure:5886: checking for strtoll configure:5886: gcc -o conftest.exe conftest.c >&5 configure:5886: $? = 0 configure:5886: result: yes Then there is many lines (at various places) with #define HAVE_STRTOLL 1 and at line 1555 ac_cv_func_strtoll=yes However corresponding generated config.h have only this #undef HAVE_STRTOLL with following redefinition of strtoll as indicated in my post before. Not sure what are you trying to achieve with strtoxx check (on my side it generates the same), the log seems to be logical: confest.exe tries to load the function with corresponding (strtoxx) name, ld does not find any and terminates - script then assumes there is no strtoxx.

#19	rokan 10:18 Jun 08, 2011

About removing strotoll from configurations: Let me check if it would work without it, maybe strtoll is only the first conflict from many (the compile then terminates). Unfortunately I have to go now, I will test it later today or tomorrow.

#20	AlbrechtS 10:30 Jun 08, 2011

That's strange. So your configure test finds strtoll(), but later it doesn't set the corresponding #define in config.h, whereas it uses "#define STRTOLL 1" in other (failed) configure tests, because only failed tests are logged with their corresponding source files. What I wanted to achieve with my "strtoxx" test was to *simulate* a "not found" error, in the assumption that this is what you got. However, your test result was different, because your test found strtoll(). I have no idea how to find the cause of your problem (as I wrote before, I can't replicate it, although we seem to have the same MinGW versions installed). BTW.: ISTR that I read somewhere in the autoconf docs that files like configh.in should _not_ contain statements like our "#ifndef HAVE_STRTOLL ...", but I don't know why this should matter. Matt, what to do now? Close w/o resolution or remove the superfluous test? Or does anybody have another idea?

#21	greg.ercolano 10:58 Jun 08, 2011

The only thing I can think of is for Roman to do a distclean, tar off his entire fltk and mingw dirs, and put it somewhere for one of us to download an try to replicate. Then perhaps we can diff the entire dirs's contents against a working build to see where the problem is. Sounds like a lot of work though.

#22	matt 12:26 Jun 08, 2011

I still don't know. Yes, first of all, if the test is not needed, it should be removed. But secondly, there must be a reason for the failure. Can you please attach the entire config.log to the STR? Maybe configh.in is messed up?

#23	AlbrechtS 12:59 Jun 08, 2011

Yes, I would also like to find the cause. As requested by Roman per PM I'm now attaching "strtoll.tgz" including my logfiles and "strtoll.txt" with the result of a grep'ing "strtoll". Maybe Roman or someone else can find a difference. Roman, please check the line endings of your files (configh.in + maybe others). Mine are LF-only (maybe this matters?). Note that I'm using Cygwin's subversion client, and "svn:eol-style native" means LF-only (not CR-LF) in this case. Which subversion client are you using, and what are your line endings? You ought to have d2u (and u2d) to change them (look for their sizes before changing them, and compare), or use od or something you know... Another idea would be to remove these (maybe) critical lines (#315-317) from configh.in just to check whether this changes anything: #ifndef HAVE_STRTOLL # define strtoll(nptr,endptr,base) strtol((nptr), (endptr), (base)) #endif /* !HAVE_STRTOLL */

#24	AlbrechtS 13:11 Jun 08, 2011

Oooohh, I got it! I just converted configh.in to Windows (DOS) format: $ u2d configh.in and ran configure again (strictly spoken: autoconf + configure), and now I can reproduce the error: I have "#undef HAVE_STRTOLL" in my config.h ! What a mess !!!! Roman, can you confirm this, and can you "fix" the error by converting configh.in (and maybe other files, if needed) to Unix format, e.g. with: $ d2u ... ?

#25	matt 13:49 Jun 08, 2011

Oh no: http://www.mikrocontroller.net/attachment/82717/Oh-No.jpg

#26	rokan 15:17 Jun 08, 2011

Oh NO!!! I can't believe that! Thanks Albrecht!!! And yes, I can confirm that "u2d -U configh.in" does the job - I have used tortoise to fetch the repository. Seems like autoconf problem (or whatever tools it uses, maybe conftest). Not sure what to do in the mean time - maybe change status of configh.in to binary within svn? Or adding some simple "bootstrap" or "create-configure" script for svn users which would invoke this u2d and also autoconf? And "thanks" to the guy (whoever it was, probably someone working with old typewriter-like printers) who thought that [CR][LF] is also a good way to finish the line and treat text files differently than binary ones. I'm sure many life-times were wasted trying to figure out bugs induced by that decision.

#27	matt 16:23 Jun 08, 2011

AFAIK the problem stems from Telex/teletype machines that required one command to return the carriage to the beginning of the paper, and a second command to roll the roller and advance the paper. CP/M and all decendents (MS-DOS, SMWindows) use CR/LF. Unix uses CR, MacOS used LF until OS 9, and the BBC machine used LF/CR. There are a number of remnants for teletype times: Unix man pages still sometimes use B<bacK>B<bacK>B<bacK>B to create a boldface character. Even in Unicode/UTF-8 we find a<BS>' to create foreign characters to this day, even though UNicode contains the accented "a". Nevertheless, I hope the person responsible is chained in hell to the guy responsible for the telephone numeric keypad being upside down to the numeric pad on keyboard! As for the solution, tagging configh.in as binary should do the job, right?

#28	AlbrechtS 00:17 Jun 09, 2011

WRT line endings: Unix uses LF, and Mac OS used to use CR, AFAICT. Is Mac OS X now using LF? As for the solution, tagging configh.in as binary would be bad, since we would lose the possibility to make diffs. svn ps svn:eol-style LF configh.in ought to do the trick (and hopefully not break anything else).

#29	matt 09:23 Jun 09, 2011

Fixed in Subversion repository. Thanks, Albrecht!