From: Martin H. <mar...@gm...> - 2009-08-23 21:02:53
|
Hi, I'm trying to build apr & apr-util (1.3.x branch from svn) with mingw (gcc 4.4.0 etc.). With a few tweaks to libtool (--no-undefined) it builds the shared libraries for both. The tests of apr run. Unfortunately the import lib for apr-util (libarputil-1.dll.a) is broken, it is just 1.5 kbyte large and includes only 2 exports. When I run make check in apr-util linking of the test program fails. I created a libarputil-1.dll.a using dlltool. Now linking works but at runtime I get a dialog complaining: "The procedure entry point apr_brigade_cleanup could not be located in the dynamic link library libaprutil-1-0.dll" The symbol is in the dll and in the dll.a file. Any idea what's going on here? -- Martin |
From: Ralf W. <Ral...@gm...> - 2009-08-25 03:22:20
|
Hello Martin, * Martin Hauner wrote on Sun, Aug 23, 2009 at 11:02:30PM CEST: > I'm trying to build apr & apr-util (1.3.x branch from svn) with mingw > (gcc 4.4.0 etc.). Which libtool version are they using? If they are still at 1.5.1x, first thing I'd try is to get them to use a newer version. > With a few tweaks to libtool (--no-undefined) it builds the shared > libraries for both. The tests of apr run. Unfortunately the import lib > for apr-util (libarputil-1.dll.a) is broken, it is just 1.5 kbyte > large and includes only 2 exports. When I run make check in apr-util > linking of the test program fails. > > I created a libarputil-1.dll.a using dlltool. Now linking works but at > runtime I get a dialog complaining: > > "The procedure entry point apr_brigade_cleanup could not be located in the > dynamic link library libaprutil-1-0.dll" > > The symbol is in the dll and in the dll.a file. Please post (cut and paste) the libool --mode=link commands that created libaprutil-1.dll.a plus all of their output, as well the link commands that create such a test, plus all of its output. Cheers, Ralf |
From: Martin H. <mar...@gm...> - 2009-08-25 21:10:47
|
Hi Ralf, On 25.08.09 05:21, Ralf Wildenhues wrote: > Hello Martin, > > * Martin Hauner wrote on Sun, Aug 23, 2009 at 11:02:30PM CEST: >> I'm trying to build apr& apr-util (1.3.x branch from svn) with mingw >> (gcc 4.4.0 etc.). > > Which libtool version are they using? If they are still at 1.5.1x, > first thing I'd try is to get them to use a newer version. I directly got the source from the svn repository and run ./buildconf. I have installed all the latest mingw autoconf/libtool stuff. As far as I understand it, apr-util uses the libtool created by apr. It says: $ /C/Development/svn-1.6.3/build-1/libtool --help ... host-triplet: i686-pc-mingw32 shell: /bin/sh compiler: gcc compiler flags: linker: c:/mingw-4.4.0/mingw32/bin/ld.exe (gnu? yes) libtool: (GNU libtool 1.3110 2009-07-01) 2.2.7a automake: automake (GNU automake) 1.11 autoconf: autoconf (GNU Autoconf) 2.63 I have edited it a bit, so it creates dlls: # Flag that allows shared libraries with undefined symbols to be built. #allow_undefined_flag="unsupported" allow_undefined_flag="yes" # Flag that enforces no undefined symbols. no_undefined_flag="--no-undefined" and I also had to use cd c:/mingw-4.4.0/share/aclocal cat lt~obsolete.m4 ltoptions.m4 ltsugar.m4 ltversion.m4 >> libtool.m4 to make apr-utils configure script work (it failed with lt_decl_varnames errors before). >> With a few tweaks to libtool (--no-undefined) it builds the shared >> libraries for both. The tests of apr run. Unfortunately the import lib >> for apr-util (libarputil-1.dll.a) is broken, it is just 1.5 kbyte >> large and includes only 2 exports. When I run make check in apr-util >> linking of the test program fails. >> >> I created a libarputil-1.dll.a using dlltool. Now linking works but at >> runtime I get a dialog complaining: >> >> "The procedure entry point apr_brigade_cleanup could not be located in the >> dynamic link library libaprutil-1-0.dll" >> >> The symbol is in the dll and in the dll.a file. > > Please post (cut and paste) the libool --mode=link commands that created > libaprutil-1.dll.a plus all of their output, as well the link commands > that create such a test, plus all of its output. I hope that's what you had in mind: linking of apr-util (I have changed libtool output from --silent to --verbose) make[1]: Entering directory `/C/Development/svn-1.6.3-build/apr-util-1.3.x' /bin/sh /C/Development/svn-1.6.3/build-1/libtool --verbose --mode=link gcc -g - O0 -Wall -DHAVE_CONFIG_H -D_LARGEFILE64_SOURCE -I/C/Development/svn-1.6.3-bu ild/apr-util-1.3.x/include -I/C/Development/svn-1.6.3-build/apr-util-1.3.x/inclu de/private -I/C/Development/svn-1.6.3/include/apr-1 -I/C/Development/svn-1.6.3 -build/apr-util-1.3.x/xml/expat/lib -version-info 3:10:3 -Wl,--enable-auto-impo rt,--subsystem,console -o libaprutil-1.la -rpath /C/Development/svn-1.6.3/lib buckets/apr_brigade.lo buckets/apr_buckets.lo buckets/apr_buckets_alloc.lo bucke ts/apr_buckets_eos.lo buckets/apr_buckets_file.lo buckets/apr_buckets_flush.lo b uckets/apr_buckets_heap.lo buckets/apr_buckets_mmap.lo buckets/apr_buckets_pipe. lo buckets/apr_buckets_pool.lo buckets/apr_buckets_refcount.lo buckets/apr_bucke ts_simple.lo buckets/apr_buckets_socket.lo crypto/apr_md4.lo crypto/apr_md5.lo c rypto/apr_sha1.lo crypto/getuuid.lo crypto/uuid.lo dbm/apr_dbm_sdbm.lo dbm/apr_d bm.lo dbm/sdbm/sdbm.lo dbm/sdbm/sdbm_hash.lo dbm/sdbm/sdbm_lock.lo dbm/sdbm/sdbm _pair.lo encoding/apr_base64.lo hooks/apr_hooks.lo ldap/apr_ldap_stub.lo ldap/ap r_ldap_url.lo misc/apr_date.lo misc/apr_queue.lo misc/apr_reslist.lo misc/apr_rm m.lo misc/apr_thread_pool.lo misc/apu_dso.lo misc/apu_version.lo memcache/apr_me mcache.lo uri/apr_uri.lo xml/apr_xml.lo strmatch/apr_strmatch.lo xlate/xlate.lo dbd/apr_dbd.lo -lrpcrt4 -lshell32 -lws2_32 -ladvapi32 -lkernel32 -lmsvcrt / C/Development/svn-1.6.3-build/apr-util-1.3.x/xml/expat/lib/libexpat.la -liconv / C/Development/svn-1.6.3/lib/libapr-1.la -lrpcrt4 -lshell32 -lws2_32 -ladvapi32 - lkernel32 -lmsvcrt libtool: link: rm -fr .libs/libaprutil-1.a .libs/libaprutil-1.dll.a .libs/libap rutil-1.la .libs/libaprutil-1.lai libtool: link: gcc -shared buckets/.libs/apr_brigade.o buckets/.libs/apr_bucket s.o buckets/.libs/apr_buckets_alloc.o buckets/.libs/apr_buckets_eos.o buckets/.l ibs/apr_buckets_file.o buckets/.libs/apr_buckets_flush.o buckets/.libs/apr_bucke ts_heap.o buckets/.libs/apr_buckets_mmap.o buckets/.libs/apr_buckets_pipe.o buck ets/.libs/apr_buckets_pool.o buckets/.libs/apr_buckets_refcount.o buckets/.libs/ apr_buckets_simple.o buckets/.libs/apr_buckets_socket.o crypto/.libs/apr_md4.o c rypto/.libs/apr_md5.o crypto/.libs/apr_sha1.o crypto/.libs/getuuid.o crypto/.lib s/uuid.o dbm/.libs/apr_dbm_sdbm.o dbm/.libs/apr_dbm.o dbm/sdbm/.libs/sdbm.o dbm/ sdbm/.libs/sdbm_hash.o dbm/sdbm/.libs/sdbm_lock.o dbm/sdbm/.libs/sdbm_pair.o enc oding/.libs/apr_base64.o hooks/.libs/apr_hooks.o ldap/.libs/apr_ldap_stub.o ldap /.libs/apr_ldap_url.o misc/.libs/apr_date.o misc/.libs/apr_queue.o misc/.libs/ap r_reslist.o misc/.libs/apr_rmm.o misc/.libs/apr_thread_pool.o misc/.libs/apu_dso .o misc/.libs/apu_version.o memcache/.libs/apr_memcache.o uri/.libs/apr_uri.o xm l/.libs/apr_xml.o strmatch/.libs/apr_strmatch.o xlate/.libs/xlate.o dbd/.libs/ap r_dbd.o /C/Development/svn-1.6.3-build/apr-util-1.3.x/xml/expat/lib/.libs/libe xpat.dll.a /mingw/lib/libiconv.dll.a /C/Development/svn-1.6.3/lib/libapr-1.dll.a -lrpcrt4 -lshell32 -lws2_32 -ladvapi32 -lkernel32 -lmsvcrt -Wl,--enable-auto-i mport -Wl,--subsystem -Wl,console -o .libs/libaprutil-1-0.dll -Wl,--enable-aut o-image-base -Xlinker --out-implib -Xlinker .libs/libaprutil-1.dll.a Creating library file: .libs/libaprutil-1.dll.a libtool: link: ar cru .libs/libaprutil-1.a buckets/apr_brigade.o buckets/apr_bu ckets.o buckets/apr_buckets_alloc.o buckets/apr_buckets_eos.o buckets/apr_bucket s_file.o buckets/apr_buckets_flush.o buckets/apr_buckets_heap.o buckets/apr_buck ets_mmap.o buckets/apr_buckets_pipe.o buckets/apr_buckets_pool.o buckets/apr_buc kets_refcount.o buckets/apr_buckets_simple.o buckets/apr_buckets_socket.o crypto /apr_md4.o crypto/apr_md5.o crypto/apr_sha1.o crypto/getuuid.o crypto/uuid.o dbm /apr_dbm_sdbm.o dbm/apr_dbm.o dbm/sdbm/sdbm.o dbm/sdbm/sdbm_hash.o dbm/sdbm/sdbm _lock.o dbm/sdbm/sdbm_pair.o encoding/apr_base64.o hooks/apr_hooks.o ldap/apr_ld ap_stub.o ldap/apr_ldap_url.o misc/apr_date.o misc/apr_queue.o misc/apr_reslist. o misc/apr_rmm.o misc/apr_thread_pool.o misc/apu_dso.o misc/apu_version.o memcac he/apr_memcache.o uri/apr_uri.o xml/apr_xml.o strmatch/apr_strmatch.o xlate/xlat e.o dbd/apr_dbd.o libtool: link: ranlib .libs/libaprutil-1.a libtool: link: creating libaprutil-1.la libtool: link: ( cd ".libs" && rm -f "libaprutil-1.la" && ln -s "../libaprutil-1 .la" "libaprutil-1.la" ) make[1]: Leaving directory `/C/Development/svn-1.6.3-build/apr-util-1.3.x' .libs/libaprutil-1.dll.a is now 1490 byte. The dll is 342 kbyte. Linking the test fails with missing symbols: /bin/sh /C/Development/svn-1.6.3/build-1/libtool --verbose --mode=link gcc -g - O0 -Wall -DHAVE_CONFIG_H -D_LARGEFILE64_SOURCE -I/C/Development/svn-1.6.3-bu ild/apr-util-1.3.x/include -I/C/Development/svn-1.6.3-build/apr-util-1.3.x/inclu de/private -I/C/Development/svn-1.6.3/include/apr-1 -I/C/Development/svn-1.6.3 -build/apr-util-1.3.x/xml/expat/lib -Wl,--enable-auto-import,--subsystem,consol e -no-install -o testall abts.lo testutil.lo teststrmatch.lo testuri.lo testu uid.lo testbuckets.lo testpass.lo testmd4.lo testmd5.lo testldap.lo testdate.lo testdbm.lo testdbd.lo testxml.lo testrmm.lo testreslist.lo testqueue.lo testxlat e.lo testmemcache.lo ../libaprutil-1.la /C/Development/svn-1.6.3-build/apr-util -1.3.x/xml/expat/lib/libexpat.la -liconv /C/Development/svn-1.6.3/lib/libapr-1.l a -lrpcrt4 -lshell32 -lws2_32 -ladvapi32 -lkernel32 -lmsvcrt libtool: link: warning: `-no-install' is ignored for i686-pc-mingw32 libtool: link: warning: assuming `-no-fast-install' instead libtool: link: gcc -g -O0 -Wall -DHAVE_CONFIG_H -D_LARGEFILE64_SOURCE -I/C/Devel opment/svn-1.6.3-build/apr-util-1.3.x/include -I/C/Development/svn-1.6.3-build/a pr-util-1.3.x/include/private -I/C/Development/svn-1.6.3/include/apr-1 -I/C/Deve lopment/svn-1.6.3-build/apr-util-1.3.x/xml/expat/lib -Wl,--enable-auto-import -W l,--subsystem -Wl,console -o .libs/testall .libs/abts.o .libs/testutil.o .libs/t eststrmatch.o .libs/testuri.o .libs/testuuid.o .libs/testbuckets.o .libs/testpas s.o .libs/testmd4.o .libs/testmd5.o .libs/testldap.o .libs/testdate.o .libs/test dbm.o .libs/testdbd.o .libs/testxml.o .libs/testrmm.o .libs/testreslist.o .libs/ testqueue.o .libs/testxlate.o .libs/testmemcache.o ../.libs/libaprutil-1.dll.a /C/Development/svn-1.6.3-build/apr-util-1.3.x/xml/expat/lib/.libs/libexpat.dll.a /mingw/lib/libiconv.dll.a /C/Development/svn-1.6.3/lib/libapr-1.dll.a -lrpcrt4 -lshell32 -lws2_32 -ladvapi32 -lkernel32 -lmsvcrt -L/C/Development/svn-1.6.3-bu ild/apr-util-1.3.x/.libs -L/C/Development/svn-1.6.3-build/apr-util-1.3.x/xml/exp at/lib/.libs -L/mingw/lib -L/C/Development/svn-1.6.3/lib -L/C/Development/svn-1. 6.3/lib -L/mingw/lib .libs/teststrmatch.o: In function `test_str': c:\Development\svn-1.6.3-build\apr-util-1.3.x\test/teststrmatch.c:44: undefined reference to `apr_strmatch_precompile' c:\Development\svn-1.6.3-build\apr-util-1.3.x\test/teststrmatch.c:47: undefined reference to `apr_strmatch_precompile' more errors follow... After creating a dll.a by hand dlltool.exe -z test.def --export-all-symbols libaprutil-1-0.dll dlltool.exe -d test.def -l libaprutil-1.dll.a (plus removing a few symbols from the def file) it links but then complains at runtime about missing symbols. Interesting is that if I use depend.exe (Dependency Walker) it says there are a lot of referenced symbols but no symbol except one is actually available in libaprutil-1-0.dll. That single available symbol is also the only symbol listed in the dll.a file created when running make. So it looks like the problem is not the creation of the dll.a but of the dll itself... Does this make sense? > Cheers, > Ralf Thanks for trying to help me :) -- Martin |
From: Martin H. <mar...@gm...> - 2009-08-30 17:59:43
|
On 23.08.09 23:02, Martin Hauner wrote: > Hi, > > I'm trying to build apr& apr-util (1.3.x branch from svn) with mingw (gcc 4.4.0 > etc.). > > With a few tweaks to libtool (--no-undefined) it builds the shared libraries for > both. The tests of apr run. Unfortunately the import lib for apr-util > (libarputil-1.dll.a) is broken, it is just 1.5 kbyte large and includes only 2 > exports. When I run make check in apr-util linking of the test program fails. Interesting is, that after removing two object files from the libtool linker input it creates a proper dll and a dll.a file. It doesn't link the test program (of course) because it has a few missing symbols defined in the two left out object files. But otherwise it looks ok. Depends.exe properly lists all other symbols as present in the dll. (dll.a size: 165.782 dll size: 337.275) If I add the two object files again, I get an dll.a file with a single symbol that is from one of the two object files. Depends.exe also just lists this single symbol as present in the dll. (dll.a size: 1490 dll size: 343.286) Why would linking with an additional object file break the dll/dll.a files? -- Martin |
From: Keith M. <kei...@us...> - 2009-08-30 20:07:30
|
On Sunday 30 August 2009 18:52:38 Martin Hauner wrote: > If I add the two object files again, I get an dll.a file with a > single symbol that is from one of the two object files. > Depends.exe also just lists this single symbol as present in the > dll. > > (dll.a size: 1490 dll size: 343.286) > > Why would linking with an additional object file break the > dll/dll.a files? SWAG: one of those object files includes a symbol, (the one which *does* show up in your DLL), which is qualified with the attribute `__declspec(dllexport)'. If you don't have any symbols decorated with this attribute, then all symbols are exported by default; as soon as any one symbol is so decorated, then only so decorated symbols will be exported, (unless you add `--export-all-symbols' to your linking command when creating the DLL). -- Regards, Keith. |
From: Martin H. <mar...@gm...> - 2009-08-31 20:23:06
|
Hi, On 30.08.09 22:06, Keith Marshall wrote: > On Sunday 30 August 2009 18:52:38 Martin Hauner wrote: >> If I add the two object files again, I get an dll.a file with a >> single symbol that is from one of the two object files. >> Depends.exe also just lists this single symbol as present in the >> dll. >> >> (dll.a size: 1490 dll size: 343.286) >> >> Why would linking with an additional object file break the >> dll/dll.a files? > > SWAG: one of those object files includes a symbol, (the one which > *does* show up in your DLL), which is qualified with the attribute > `__declspec(dllexport)'. If you don't have any symbols decorated > with this attribute, then all symbols are exported by default; as > soon as any one symbol is so decorated, then only so decorated > symbols will be exported, (unless you add `--export-all-symbols' > to your linking command when creating the DLL). Ah, indeed, that's the problem. After adding --export-all-symbols I get a working dll.a. :-) I tried to find the "wrong" dllexport, I think I found it but removing it did not help. Strange. But I guess using --export-all-symbols is easier anyway as I don't have to touch the source code. Thanks! -- Martin |