-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
I'm trying to build crystalspace.dll using mingw within the cygwin
framework (i.e. -mno-cygwin). Everything works fine up until it actually
links the dll, when things go horribly wrong...
$ jam crystalspace
# .. stuff compiles without error ...
dllwrap --driver-name=g++ -mno-cygwin --dllname crystalspace-GCC.dll
- --def=./out/msysx86/optimize/libs/crystalspace-GCC.dll.def --implib
./out/msysx86/optimize/libs/libcrystalspace.a -o crystalspace-GCC.dll
./out/msysx86/optimize/libs/crystalspace-GCC.dll.a
- -L/cygdrive/c/hack/CrystalSpaceLibs/lib
- -L/cygdrive/c/hack/CrystalSpaceLibs/lib/cygwin
- -L/cygdrive/c/hack/CrystalSpaceLibs/lib/cygwin-gcc-3.4 -lm
- -L/usr/local/lib -L/usr/lib/w32api -lgdi32 -lshell32 -lz
- -L/cygdrive/c/hack/CrystalSpaceLibs/lib
- -L/cygdrive/c/hack/CrystalSpaceLibs/lib/cygwin
- -L/cygdrive/c/hack/CrystalSpaceLibs/lib/cygwin-gcc-3.4 -lm -L/usr/local/lib
- -L/usr/lib/w32api -lgdi32 -lshell32
touch ./out/msysx86/optimize/libs/libcrystalspace.a # ensure the IMPLIB
is always newer than the DLL,
# since the IMPLIB depends on the DLL.
/usr/lib/gcc/i686-pc-mingw32/3.4.4/../../../../i686-pc-mingw32/bin/ld:
warning:
cannot find entry symbol [EMAIL PROTECTED]; defaulting to 62901000
/usr/lib/gcc/i686-pc-mingw32/3.4.4/../../../../i686-pc-mingw32/bin/ld:
warning:
cannot find entry symbol [EMAIL PROTECTED]; defaulting to 62901000
fu000001.o:: undefined reference to `_libmsvcrt_a_iname'
fu000002.o:: undefined reference to `_libmsvcrt_a_iname'
fu000003.o:: undefined reference to `_libmsvcrt_a_iname'
fu000004.o:: undefined reference to `_libmsvcrt_a_iname'
fu000005.o:: undefined reference to `_libmsvcrt_a_iname'
fu000006.o:: more undefined references to `_libmsvcrt_a_iname' follow
nmth000000.o:: undefined reference to `__nm__atexit'
Info: resolving _atexit by linking to __imp__atexit (auto-import)
collect2: ld returned 1 exit status
dllwrap: g++ exited with status 1
I have searched google top, down and sideways for anyone that has made
heads or tails of this error, and although there are dozens instances of
people a similar error, for solutions I have come up empty handed (well...
except for one tantalizing posibility that also happened to be written in
Russian, so who knows). I am utterly baffled and frustrated and don't
really know what do to next. There is a special circle of hell reserved
for debugging linker errors, and I'm in it.
For reference, here's how I'm configuring crystalspace. Setting CC/CXX in
this way is the preferred way of directing cygwin to use mingw, since in
fact it goes and actually calls a separate toolchain for mingw (so it
really is running an entirely different compiler).
./configure CC="gcc -mno-cygwin" CXX="g++ -mno-cygwin"
CPP="gcc -mno-cygwin -E" --enable-shared
A couple things I noticed...
- - CS has a test for libtool, but doesn't seem to be using it. Anywhere.
Why is this? libtool works just fine on cygwin, and indeed compiling
libraries and modules portably is what libtool is for. Dllwrap and
dlltool are simply evil.
- - CS seems to be taking a rather roundabout way of generating the DLL, by
first creating a static library and then exporting symbols from it. Why
not link the dll directly? I dare say this approach isn't making the
problem diagnosis any easier.
- - I've tried a couple different versions of crystalspace (one from shortly
before the SVN migration) and various combinations of options, but to no
avail. There is some deeper problem going on here.
- - The "_iname" symbol seems to have some special linkage function for
DLLs, but I can't find any documentation on it. Every single DLL I have
looked at appears to leave this symbol undefined?! (according to nm)
- - I haven't ming/msys yet. I have no idea if it produces the same results
or not.
- - Here's how I ended up in this predicament: I am trying to compile a CS
plugin (the VOS plugin) outside of the CS tree, using libtool instead of
the CS build system. Now, DLLs can't have undefined symbols, so the
plugin must link to libcrystalspace. However, libtool doesn't allow
linking static libraries to dynamic libraries because it is nonportable
(on certain platforms it would invite symbol collisions, I think). I
can't override libtool. Thus, I need libcrystalspace to be a DLL in order
to link the plugin DLL against it.
I presume that CS ducks this issue by implementing its own build process
for DLLs that is a little more lenient (or at least knows to prevent the
libcrystalspace symbols from being exported).
I would appreciate any insight anyone has into this problem.
[ Peter Amstutz ][ [EMAIL PROTECTED] ][ [EMAIL PROTECTED] ]
[Lead Programmer][Interreality Project][Virtual Reality for the Internet]
[ VOS: Next Generation Internet Communication][ http://interreality.org ]
[ http://interreality.org/~tetron ][ pgpkey: pgpkeys.mit.edu 18C21DF7 ]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
iD8DBQFEhRuGaeHUyhjCHfcRAmJOAJ4hhAQ0bdVZzPVcwc6THhbzHDDYrwCeJlZV
mjM6C4RpMikTCESzTsqRtto=
=WwV9
-----END PGP SIGNATURE-----
_______________________________________________
Crystal-main mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/crystal-main
Unsubscribe: mailto:[EMAIL PROTECTED]
