Error compiling libcurl / ares w/ MinGW
Archives Forums/Win32 Discussion/Error compiling libcurl / ares w/ MinGW
| ||
| Hi, I'm sure this is old news for many of you, but I'm relatively new to getting MingW working w/ BlitzMax on a PC. On my Windows 7 Home Edition/ AMD64 machine with MaxIDE 1.41, FASM 1.68, GCC 4.5.2 and G++ 4.5.2, I get the following errors when trying to rebuild all of my modules (which includes the bah.libcurl). (also, just for reference, I have already: • copied the ld.exe and ar.exe binaries that shipped with MinGW to BlitzMax/bin • added the imports (e.g. libc++) to blitz.bmx in brl.mod
Compiling:ares_fds.c
In file included from c:\mingw\bin\../lib/gcc/mingw32/4.5.2/../../../../include/stdio.h:534:0,
from C:/BlitzMax/mod/bah.mod/libcurl.mod/src/ares/setup_once.h:34,
from C:/BlitzMax/mod/bah.mod/libcurl.mod/src/ares/setup.h:162,
from C:/BlitzMax/mod/bah.mod/libcurl.mod/src/ares/ares_fds.c:18:
c:\mingw\bin\../lib/gcc/mingw32/4.5.2/../../../../include/sys/types.h:119:18: error: two or more data types in declaration specifiers
Build Error: failed to compile C:/BlitzMax/mod/bah.mod/libcurl.mod/src/ares/ares_fds.c
Process complete
It sounds like its referring to some errors with regard to (duplicate?) declarations of the ssize_t family of typedefs. The part in types.h that it is calling out is: #ifndef _SSIZE_T_ #define _SSIZE_T_ typedef long _ssize_t; #ifndef _NO_OLDNAMES typedef _ssize_t ssize_t; #endif #endif /* Not _SSIZE_T_ */ I'm at a loss for what's going on. Been banging my head on it for a while. Any ideas what's causing the errors? Thanks, Jason Last edited 2011 Last edited 2011 |
| ||
| Did you also overwrite the files under blitzmax/lib with their equivalents out of your MinGW install? The ones bundled with Blitzmax are 3.x versions, which won't work properly if you're using a newer mingw install. |
| ||
| I will try that out and get back to you! Thanks xlsior. |
| ||
Tried it, and unfortunately it's still failing in the same spot:
Compiling:splay.c
Compiling:strdup.c
Compiling:socks.c
Compiling:ssh.c
Compiling:nss.c
Compiling:ares_fds.c
In file included from c:\mingw\bin\../lib/gcc/mingw32/4.5.2/../../../../include/stdio.h:534:0,
from C:/BlitzMax/mod/bah.mod/libcurl.mod/src/ares/setup_once.h:34,
from C:/BlitzMax/mod/bah.mod/libcurl.mod/src/ares/setup.h:162,
from C:/BlitzMax/mod/bah.mod/libcurl.mod/src/ares/ares_fds.c:18:
c:\mingw\bin\../lib/gcc/mingw32/4.5.2/../../../../include/sys/types.h:119:18: error: two or more data types in declaration specifiers
Build Error: failed to compile C:/BlitzMax/mod/bah.mod/libcurl.mod/src/ares/ares_fds.c
Process complete
|
| ||
I've since updated the ares source code to the latest that is available from their repository. Now ares_fds.c compiles but it fails a few files later:
Compiling:ares_inet_ntop.c
In file included from c:\mingw\bin\../lib/gcc/mingw32/4.5.2/../../../../include/stdio.h:534:0,
from C:/BlitzMax/mod/bah.mod/libcurl.mod/src/ares/setup_once.h:33,
from C:/BlitzMax/mod/bah.mod/libcurl.mod/src/ares/setup.h:162,
from C:/BlitzMax/mod/bah.mod/libcurl.mod/src/ares/ares_inet_ntop.c:19:
c:\mingw\bin\../lib/gcc/mingw32/4.5.2/../../../../include/sys/types.h:119:18: error: two or more data types in declaration specifiers
Build Error: failed to compile C:/BlitzMax/mod/bah.mod/libcurl.mod/src/ares/ares_inet_ntop.c
Process complete
still investigating to see what's up... |
| ||
| Is this any use? http://blitzbasic.com/Community/posts.php?topic=90964#1064278? I recently reinstalled and used the MinGW from there, everything worked fine for me. |
| ||
| Something else: after replacing the lib versions, you'll need to recompile -all- your modules or you may still run into issues like this. Your existing brl.mod, pub.mod, etc. will have been compiled against the old libraries, and new modules that have dependencies on these older mods may have the kind of problem that you're running into here. Try this: blitzmax\bin\bmk makemods -a brl.mod blitzmax\bin\bmk makemods -a -h brl.mod blitzmax\bin\bmk makemods -a blitzmax\bin\bmk makemods -a -h This will first recompile your brl.mod against your current MinGW with the latest libraries, and recompile brl.mod in threaded mode, and then do everything else. (the -a forces a recompile even if it thinks it's already good to go as-is, the -h compiled the threaded version) |
| ||
| @Perturbatio: Did you download the MinGW linked that post, or from their actual site? I followed those some directions, but I downloaded from the site instead of the link posted. @xlsior: I tried following the re-compilation steps as you said, and I'm still getting the same error :( |
| ||
| from the post |
| ||
Thanks, using the MinGW from the post did get all the modules to compile. There does still seem to be a problem with libcurl though when being linked into an app. When I try to build an app with BaH.mod, it compiles fine and then fails linking:Building client Compiling:client.bmx flat assembler version 1.68 (1471188 kilobytes memory) 5 passes, 1.0 seconds, 2751071 bytes. Linking:client.debug.mt.exe C:/BlitzMax/mod/bah.mod/libcurl.mod/libcurl.debug.mt.win32.x86.a(easy.c.debug.mt.win32.x86.o):easy.c:(.text+0x65c): undefined reference to `_imp__ares_init' C:/BlitzMax/mod/bah.mod/libcurl.mod/libcurl.debug.mt.win32.x86.a(url.c.debug.mt.win32.x86.o):url.c:(.text+0x40e): undefined reference to `_imp__ares_destroy' C:/BlitzMax/mod/bah.mod/libcurl.mod/libcurl.debug.mt.win32.x86.a(url.c.debug.mt.win32.x86.o):url.c:(.text+0x72a): undefined reference to `_imp__ares_init' C:/BlitzMax/mod/bah.mod/libcurl.mod/libcurl.debug.mt.win32.x86.a(url.c.debug.mt.win32.x86.o):url.c:(.text+0x99b): undefined reference to `_imp__ares_destroy' C:/BlitzMax/mod/bah.mod/libcurl.mod/libcurl.debug.mt.win32.x86.a(url.c.debug.mt.win32.x86.o):url.c:(.text+0x601e): undefined reference to `_imp__ares_cancel' C:/BlitzMax/mod/bah.mod/libcurl.mod/libcurl.debug.mt.win32.x86.a(hostares.c.debug.mt.win32.x86.o):hostares.c:(.text+0x1c): undefined reference to `_imp__ares_getsock' C:/BlitzMax/mod/bah.mod/libcurl.mod/libcurl.debug.mt.win32.x86.a(hostares.c.debug.mt.win32.x86.o):hostares.c:(.text+0x4d): undefined reference to `_imp__ares_timeout' C:/BlitzMax/mod/bah.mod/libcurl.mod/libcurl.debug.mt.win32.x86.a(hostares.c.debug.mt.win32.x86.o):hostares.c:(.text+0xd7): undefined reference to `_imp__ares_getsock' C:/BlitzMax/mod/bah.mod/libcurl.mod/libcurl.debug.mt.win32.x86.a(hostares.c.debug.mt.win32.x86.o):hostares.c:(.text+0x234): undefined reference to `_imp__ares_process_fd' C:/BlitzMax/mod/bah.mod/libcurl.mod/libcurl.debug.mt.win32.x86.a(hostares.c.debug.mt.win32.x86.o):hostares.c:(.text+0x2df): undefined reference to `_imp__ares_process_fd' C:/BlitzMax/mod/bah.mod/libcurl.mod/libcurl.debug.mt.win32.x86.a(hostares.c.debug.mt.win32.x86.o):hostares.c:(.text+0x346): undefined reference to `_imp__ares_strerror' C:/BlitzMax/mod/bah.mod/libcurl.mod/libcurl.debug.mt.win32.x86.a(hostares.c.debug.mt.win32.x86.o):hostares.c:(.text+0x46e): undefined reference to `_imp__ares_timeout' C:/BlitzMax/mod/bah.mod/libcurl.mod/libcurl.debug.mt.win32.x86.a(hostares.c.debug.mt.win32.x86.o):hostares.c:(.text+0x52d): undefined reference to `_imp__ares_cancel' C:/BlitzMax/mod/bah.mod/libcurl.mod/libcurl.debug.mt.win32.x86.a(hostares.c.debug.mt.win32.x86.o):hostares.c:(.text+0x5a9): undefined reference to `_imp__ares_strerror' C:/BlitzMax/mod/bah.mod/libcurl.mod/libcurl.debug.mt.win32.x86.a(hostares.c.debug.mt.win32.x86.o):hostares.c:(.text+0x6b8): undefined reference to `_imp__ares_gethostbyname' C:/BlitzMax/lib/libgcc.a(__main.o):(.text+0x4f): undefined reference to `__EH_FRAME_BEGIN__' C:/BlitzMax/lib/libgcc.a(__main.o):(.text+0x73): undefined reference to `__EH_FRAME_BEGIN__' Build Error: Failed to link C:/Users/jason/Documents/Phoenix/client/client.debug.mt.exe Process complete This even happens if I try to compile sample code from BRL. It fails on linking libgcc. Not sure where all these linking errors are coming from, I see the necessary library files in BlitzMax's directory, but I'm not sure how bmk links these in. Last edited 2011 |
| ||
| I feel this problem is akin to what was discussed here: http://www.blitzbasic.com/Community/posts.php?topic=84925 , but I have still yet to crack it. I've never really dug into the details behind bmk and the order in which it links libraries...I guess I'm going to have to now! |
| ||
Here's what happens when trying to build one of the BlitzMax samples:Building astar_demo Compiling:priority_queue.bmx flat assembler version 1.68 (1462079 kilobytes memory) 4 passes, 16011 bytes. Compiling:astar_node.bmx flat assembler version 1.68 (1462301 kilobytes memory) 3 passes, 9547 bytes. Compiling:Callback.bmx flat assembler version 1.68 (1462559 kilobytes memory) 3 passes, 3100 bytes. Compiling:astar_graph_walker.bmx flat assembler version 1.68 (1462659 kilobytes memory) 4 passes, 17971 bytes. Compiling:astar_demo.bmx flat assembler version 1.68 (1463001 kilobytes memory) 4 passes, 71466 bytes. Linking:astar_demo.debug.mt.exe C:/BlitzMax/lib/libgcc.a(__main.o):(.text+0x4f): undefined reference to `__EH_FRAME_BEGIN__' C:/BlitzMax/lib/libgcc.a(__main.o):(.text+0x73): undefined reference to `__EH_FRAME_BEGIN__' Build Error: Failed to link C:/BlitzMax/samples/aaronkoolen/AStar/astar_demo.debug.mt.exe Process complete |
| ||
| disable threaded build |
| ||
| I tried disabling threaded building and it still doesn't compile. Plus I use threads in my project, so I need em. Is there anyway to inspect the order in which static libraries are linked in, or would that require editing bmk's source? I think I'm going to delete all of MinGW and start from scratch again :( |
| ||
| Re-installed BlitzMax, re-installed MinGW, re-installed MaxGUI and all the other mods, rebuilt everything ----- still the same exact linking error. bawls. |
| ||
| Interesting that you are having so many problems. You may want to try this and see if it helps with the link ordering. The FRAME_BEGIN issue is due to the order of .a files being wrong for this version of gcc. I had this issue when I was getting cross-compiling working on Mac/Linux. |
| ||
| That did the trick to get the sample to compile!... ...once! I ran the sample fine, and then trying to do compile it again ---- back to the same error. I wish I had a more detailed description of what's going on, but that's what I'm getting on my end. Are there any differences/advantages of rebuilding all modules via command line / bmk vs. MaxIDE? My assumption was that they would be functionally equivalent, but perhaps no. |
| ||
| Is it essential you use latest MinGW? |
| ||
| Not to my knowledge. I started off with the newest MinGW just because I thought that would be the best thing to do, but I've since switch back to the one referenced in the directions to set up MiniB3D and BMK NG. |
   |