From: Tod T. <tt...@ch...> - 2003-03-12 18:23:55
|
I have a C program that I'm porting over to windows from unix. I have the windows dll's that contain the api calls necessary to get it to compile. When I try to compile with: gcc -Wall -o myprog.exe myprog.o -L./ldapsdk/lib -L/mingw/lib -lnss3 -lssl3 -llibnspr4 -llibplc4 -llibplds4 -lnsldap32v50 -lnsldappr32v50 -lnsldapssl32v50 it fails with the following: myprog.o(.text+0x3da):myprog.c: undefined reference to `ldap_modify_ext_s@20' myprog.o(.text+0x40a):myprog.c: undefined reference to `ldap_unbind@4' myprog.o(.text+0x420):myprog.c: undefined reference to `ldap_unbind@4' myprog.o(.text+0x521):myprog.c: undefined reference to `ldap_init@8' myprog.o(.text+0x562):myprog.c: undefined reference to `ldap_simple_bind_s@12' myprog.o(.text+0x57b):myprog.c: undefined reference to `ldap_simple_bind_s@12' myprog.o(.text+0x7ab):myprog.c: undefined reference to `ldap_search_s@28' myprog.o(.text+0x7c9):myprog.c: undefined reference to `ldap_first_entry@8' myprog.o(.text+0x7dd):myprog.c: undefined reference to `ldap_get_dn@8' myprog.o(.text+0x7f6):myprog.c: undefined reference to `ldap_explode_dn@8' myprog.o(.text+0x879):myprog.c: undefined reference to `ldap_memfree@4' All of the supporting dll's are in the ./ldapsdk/lib directory, each -l represents one of the dll's I'm including in the compile. What am I missing here? Thanks. |
From: Christopher S. <cl...@se...> - 2003-03-13 19:22:58
|
Tod Thomas wrote: > I have a C program that I'm porting over to windows from unix. I have the > windows dll's that contain the api calls necessary to get it to compile. When I > try to compile with: > > gcc -Wall -o myprog.exe myprog.o -L./ldapsdk/lib -L/mingw/lib -lnss3 -lssl3 > -llibnspr4 -llibplc4 -llibplds4 -lnsldap32v50 -lnsldappr32v50 -lnsldapssl32v50 The link order is wrong. It should be LDAP_LIBS NSS_LIBS NSPR_LIBS. > it fails with the following: > > myprog.o(.text+0x3da):myprog.c: undefined reference to `ldap_modify_ext_s@20' > myprog.o(.text+0x40a):myprog.c: undefined reference to `ldap_unbind@4' How are you building LDAP? The changes to support mingw just landed in cvs last week. It looks like it wasn't linked with --export-all-symbols. What does 'nm libnsldap32v50 | grep ldap_unbind' return? - cls |
From: Earnie B. <ear...@ya...> - 2003-03-13 19:35:35
|
Christopher Seawood wrote: > > How are you building LDAP? The changes to support mingw just landed in > cvs last week. It looks like it wasn't linked with > --export-all-symbols. What does 'nm libnsldap32v50 | grep ldap_unbind' > return? > MinGW only works properly with CVS version of libtool. Hopefully a release of libtool HEAD will be soon forth coming. Earnie. |
From: Christopher S. <cl...@se...> - 2003-03-13 20:21:59
|
Earnie Boyd wrote: > Christopher Seawood wrote: > >> >> How are you building LDAP? The changes to support mingw just landed >> in cvs last week. It looks like it wasn't linked with >> --export-all-symbols. What does 'nm libnsldap32v50 | grep >> ldap_unbind' return? >> > > MinGW only works properly with CVS version of libtool. Hopefully a > release of libtool HEAD will be soon forth coming. That's ok. Mozilla doesn't use libtool to build. - cls |
From: Tod T. <tt...@ch...> - 2003-03-14 01:20:13
|
Christopher Seawood wrote: > Tod Thomas wrote: > > I have a C program that I'm porting over to windows from unix. I have the > > windows dll's that contain the api calls necessary to get it to compile. When I > > try to compile with: > > > > gcc -Wall -o myprog.exe myprog.o -L./ldapsdk/lib -L/mingw/lib -lnss3 -lssl3 > > -llibnspr4 -llibplc4 -llibplds4 -lnsldap32v50 -lnsldappr32v50 -lnsldapssl32v50 > > The link order is wrong. It should be LDAP_LIBS NSS_LIBS NSPR_LIBS. > > Link order. Should that ever matter? I've compiled the same code using the same Makefile under cygwin and got it to work. Unfortunately, I get the same undefined reference errors when I use the -mno-cygwin flag to gcc. > > > it fails with the following: > > > > myprog.o(.text+0x3da):myprog.c: undefined reference to `ldap_modify_ext_s@20' > > myprog.o(.text+0x40a):myprog.c: undefined reference to `ldap_unbind@4' > > How are you building LDAP? I'm using pre-compiled binaries from Sun's Directory SDK for Windows. > The changes to support mingw just landed in > cvs last week. It looks like it wasn't linked with > --export-all-symbols. What does 'nm libnsldap32v50 | grep ldap_unbind' > return? > > - cls > nm nsldap32v50.lib|grep ldap_unbind 00000000 I __imp__ldap_unbind@4 00000000 T _ldap_unbind@4 00000000 I __imp__ldap_unbind_ext@12 00000000 T _ldap_unbind_ext@12 00000000 I __imp__ldap_unbind_s@4 00000000 T _ldap_unbind_s@4 > uname -a MINGW32_NT-4.0 machinename 1.0.8(0.46/3/2) 2002-12-09 07:58 i686 unknown As it turns out, I went a little overboard with the included .dlls the first time around, the revised version: gcc -Wall -Wl,--export-all-symbols myprog.c -o myprog.exe -L./ldapsdk/lib -L/mingw/lib -lnsldap32v50 -I./ldapsdk/include C:\TEMP/ccedaaaa.o(.text+0x3da):passwdChg.c: undefined reference to `ldap_modify_ext_s@20' C:\TEMP/ccedaaaa.o(.text+0x40a):passwdChg.c: undefined reference to `ldap_unbind@4' C:\TEMP/ccedaaaa.o(.text+0x420):passwdChg.c: undefined reference to `ldap_unbind@4' C:\TEMP/ccedaaaa.o(.text+0x521):passwdChg.c: undefined reference to `ldap_init@8' C:\TEMP/ccedaaaa.o(.text+0x562):passwdChg.c: undefined reference to `ldap_simple_bind_s@12' C:\TEMP/ccedaaaa.o(.text+0x57b):passwdChg.c: undefined reference to `ldap_simple_bind_s@12' C:\TEMP/ccedaaaa.o(.text+0x7ab):passwdChg.c: undefined reference to `ldap_search_s@28' C:\TEMP/ccedaaaa.o(.text+0x7c9):passwdChg.c: undefined reference to `ldap_first_entry@8' C:\TEMP/ccedaaaa.o(.text+0x7dd):passwdChg.c: undefined reference to `ldap_get_dn@8' C:\TEMP/ccedaaaa.o(.text+0x7f6):passwdChg.c: undefined reference to `ldap_explode_dn@8' C:\TEMP/ccedaaaa.o(.text+0x879):passwdChg.c: undefined reference to `ldap_memfree@4' Still returns the same errors, regardless of the presence of the --export-all-symbols linker option. For what its worth here's a list of my ./ldapsdk/lib directory: lst ./ldapsdk/lib total 1112 drwxr-xr-x 3 tthomas Administ 20480 Mar 13 20:06 . -rw-r--r-- 1 tthomas Administ 7772 Mar 13 10:31 nsldappr32v50.a -rw-r--r-- 1 tthomas Administ 8526 Mar 13 10:31 nsldapssl32v50.a -rw-r--r-- 1 tthomas Administ 180686 Mar 13 10:31 nsldap32v50.a -rw-r--r-- 1 tthomas Administ 29336 Mar 13 10:31 libplc4.a -rw-r--r-- 1 tthomas Administ 19344 Mar 13 10:31 libplds4.a -rw-r--r-- 1 tthomas Administ 269326 Mar 13 10:31 libnspr4.a -rw-r--r-- 1 tthomas Administ 37528 Mar 13 10:31 ssl3.a -rw-r--r-- 1 tthomas Administ 340164 Mar 13 10:31 nss3.a -rw-r--r-- 1 tthomas Administ 36264 Mar 12 14:04 nslber32v50.lib -rw-r--r-- 1 tthomas Administ 56004 Mar 12 14:04 nsldap32v50.lib -rw-r--r-- 1 tthomas Administ 3900 Mar 12 14:04 nsldappr32v50.lib -rw-r--r-- 1 tthomas Administ 4150 Mar 12 14:04 nsldapssl32v50.lib -rw-r--r-- 1 tthomas Administ 8176 Mar 12 14:04 nsldif32v50.lib -rw-r--r-- 1 tthomas Administ 105702 Mar 12 14:04 nss3.lib -rw-r--r-- 1 tthomas Administ 2744 Mar 12 14:04 nsutil32v50.lib -rw-r--r-- 1 tthomas Administ 13002 Mar 12 14:04 ssl3.lib -rw-r--r-- 1 tthomas Administ 78448 Mar 12 14:04 libnspr4.lib -rw-r--r-- 1 tthomas Administ 9112 Mar 12 14:04 libplc4.lib -rw-r--r-- 1 tthomas Administ 7050 Mar 12 14:04 libplds4.lib -rw-r--r-- 1 tthomas Administ 1932 Mar 12 14:04 nsiutil32v50.lib drwxr-xr-x 8 tthomas Administ 4096 Mar 12 10:38 .. -rwxr-xr-x 1 tthomas Administ 475136 Feb 27 2002 nss3.dll -rwxr-xr-x 1 tthomas Administ 106496 Feb 27 2002 ssl3.dll -rwxr-xr-x 1 tthomas Administ 184320 Feb 27 2002 libnspr4.dll -rwxr-xr-x 1 tthomas Administ 28672 Feb 27 2002 libplc4.dll -rwxr-xr-x 1 tthomas Administ 24576 Feb 27 2002 libplds4.dll -rwxr-xr-x 1 tthomas Administ 139264 Feb 27 2002 nsldap32v50.dll -rwxr-xr-x 1 tthomas Administ 24576 Feb 27 2002 nsldappr32v50.dll -rwxr-xr-x 1 tthomas Administ 40960 Feb 27 2002 nsldapssl32v50.dll Thanks for the feedback - Tod |
From: Christopher S. <cl...@se...> - 2003-03-14 01:47:13
|
Tod Thomas wrote: > Christopher Seawood wrote: > Link order. Should that ever matter? It usually depends upon your linker. In my experiece with mingw, link order matters. >>How are you building LDAP? > > > I'm using pre-compiled binaries from Sun's Directory SDK for Windows. Oh, so the bins you're using were probably compiled with msvc. Nevermind. > >>The changes to support mingw just landed in >>cvs last week. It looks like it wasn't linked with >>--export-all-symbols. What does 'nm libnsldap32v50 | grep ldap_unbind' >>return? > gcc -Wall -Wl,--export-all-symbols myprog.c -o myprog.exe -L./ldapsdk/lib > -L/mingw/lib -lnsldap32v50 -I./ldapsdk/include Actually, I was referring to the need to use --export-all-symbols when building LDAP. Since you're using a precompiled version that doesn't matter. I'm not sure what's necessary to convert the MSVC built libs into a form suitable for mingw though I'm sure it's in a FAQ somewhere. - cls |
From: Earnie B. <ear...@ya...> - 2003-03-14 12:40:33
|
Christopher Seawood wrote: > > I'm not sure what's necessary to convert the MSVC built libs into a form > suitable for mingw though I'm sure it's in a FAQ somewhere. > Is the library a C++ library? Earnie. |
From: TROCHU X. <xt...@ya...> - 2003-03-14 13:07:49
|
--- Earnie Boyd <ear...@ya...> wrote: > > Is the library a C++ library? > > Earnie. > I see that you're going to say that dll compiled with MSVC that export C++ classes/methods are not compatible with Mingw, in the sense that you can't link with them. I understand that the name mangling mechanism is different between MSVC and GCC, so the linker can't find matching names, but I want to know if there are other reasons that makes GCC and MSVC C++ non-compatible. Someone said previously on this list that the ABI is different, and that even if it was possible to alias the mangled names to achieve compilation, the resulting code would fail to execute correctly. My point is : _ C ABI are the same for both compilers. Whatever complex structure you pass from one to the other is correctly read if the alignement is the same. _ Virtual Tables looks like they are the same, because using COM with Mingw is possible. So what other difference exist ? Greetings, Xavier __________________________________________________ Do you Yahoo!? Yahoo! Web Hosting - establish your business online http://webhosting.yahoo.com |
From: Earnie B. <ear...@ya...> - 2003-03-14 13:46:03
|
TROCHU Xavier wrote: > --- Earnie Boyd <ear...@ya...> wrote: > >>Is the library a C++ library? >> >>Earnie. >> > > > I see that you're going to say that dll compiled with > MSVC that export C++ classes/methods are not > compatible with Mingw, in the sense that you can't > link with them. > You cannot link directly with them. You can use LoadLibarary and GetProcAddress in your program directly or create a wrapper library that uses LoadLibarary and GetProdAddress that will resolve it for you. The only difference that I know is the name mangling for C++ between GCC and MSVC and BORLAND and WATCOM and ... But, LoadLibrary and GetProcAddress are your friends, use them. > I understand that the name mangling mechanism is > different between MSVC and GCC, so the linker can't > find matching names, but I want to know if there are > other reasons that makes GCC and MSVC C++ > non-compatible. > > Someone said previously on this list that the ABI is > different, and that even if it was possible to alias > the mangled names to achieve compilation, the > resulting code would fail to execute correctly. > You'll have to ask that someone what they meant. > My point is : > _ C ABI are the same for both compilers. Whatever > complex structure you pass from one to the other is > correctly read if the alignement is the same. > _ Virtual Tables looks like they are the same, because > using COM with Mingw is possible. > > So what other difference exist ? > I don't know that there are any. Earnie. |
From: TROCHU X. <xt...@ya...> - 2003-03-14 16:03:30
|
--- Earnie Boyd <ear...@ya...> wrote: > The only difference that I know is the name mangling > for C++ between GCC > and MSVC and BORLAND and WATCOM and ... But, > LoadLibrary and > GetProcAddress are your friends, use them. > Hmm... But you'll still have issue with non virtual member functions. I don't think you can't link to these at runtime. Or more likely your code will fail to link. > > <SNIP> > > I don't know that there are any. > So one could imagine that reimp could be updated to detect "VC style" mangled name in import library and create an alias to a "GCC style" mangled name, thus resolving the linking with Visual C++ DLLs issue that occur quite often on this list. I am absolutely not familiar with the algorithm used for name mangling by any of these compiler except that I used API that demangle name for both compiler, namely abi::__cxa_demangle() for mingw and UnDecorateSymbolName() for VC, so I am quite sure that performing mangled -> demangled name conversion does not require intimate knowledge about the class itself. This is just an idea, Thanks for the quick reply, Xavier > Earnie. > > > > ------------------------------------------------------- > This SF.net email is sponsored by:Crypto Challenge > is now open! > Get cracking and register here for some mind > boggling fun and > the chance of winning an Apple iPod: > http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en > _______________________________________________ > MinGW-users mailing list > Min...@li... > > You may change your MinGW Account Options or > unsubscribe at: > https://lists.sourceforge.net/lists/listinfo/mingw-users __________________________________________________ Do you Yahoo!? Yahoo! Web Hosting - establish your business online http://webhosting.yahoo.com |
From: Benjamin R. <Ben...@ep...> - 2003-03-14 14:25:48
|
Hi Xavier, TROCHU Xavier <xt...@ya...> writes: > _ Virtual Tables looks like they are the same, because > using COM with Mingw is possible. > > So what other difference exist ? There are a couple of other areas in C++ that are not covered by COM. Issues that come to my mind immediately: Calls to non-virtual methods, handling of multiple inheritance, exception handling, layout and internal usage of RTTI, dynamic_cast<> mechanism, probably more. Some of these may be similar to VC++, but several of them are surely different. so long, benny |
From: Oscar F. <of...@wa...> - 2003-03-14 21:34:16
|
Benjamin Riefenstahl <Ben...@ep...> writes: > > _ Virtual Tables looks like they are the same, because > > using COM with Mingw is possible. > > > > So what other difference exist ? > > There are a couple of other areas in C++ that are not covered by COM. > Issues that come to my mind immediately: Calls to non-virtual > methods, Indeed. MSVC++ passes 'this' on the ECX register, g++ passes 'this' on the stack. I think there are not options to change this behavior. > handling of multiple inheritance, exception handling, layout and > internal usage of RTTI, dynamic_cast<> mechanism, probably more. Some > of these may be similar to VC++, but several of them are surely > different. -- Oscar |
From: Don S. <dr...@su...> - 2003-03-21 21:29:17
|
Oscar, Why is your e-mail address, of...@wa..., blacklisted by SpamCop? Don |
From: Christopher S. <cl...@se...> - 2003-03-14 22:18:59
|
Earnie Boyd wrote: > Christopher Seawood wrote: > >> >> I'm not sure what's necessary to convert the MSVC built libs into a >> form suitable for mingw though I'm sure it's in a FAQ somewhere. >> > > Is the library a C++ library? No, the LDAP, NSS & NSPR libraries are all C libraries. - cls |