Re: Link Problem on Windows
On Thu, 2005-06-02 at 16:13 +0100, Martyn Russell wrote: Hi, I am currently having problems linking in libpq (Postgres client front end) from PostgreSQL 8.0.2. I downloaded the source and installed it under MSYS/MinGW (to /usr/local). The .dll and the .a are in /usr/local/pgsql/lib. I have tried using -L/usr/local/pgsql/lib -lpq but it fails miserably, I get the following: *** Warning: linker path does not have real file for library -lpq. *** I have the capability to make that library automatically link in when *** you link to this library. But I can only do this if you have a *** shared version of the library, which you do not appear to have *** because I did check the linker path looking for a file starting *** with libpq and none of the candidates passed a file format test *** using a file magic. Last file checked: C:/msys/1.0/local/pgsql/lib/libpq.dll *** The inter-library dependencies that have been dropped here will be *** automatically added whenever a program is linked with this library *** or is declared to -dlopen it. *** Since this library must not contain undefined symbols, *** because either the platform does not support them or *** it was explicitly requested with -no-undefined, *** libtool will only create a static version of it. OK, just thought I would post my progress on this. Basically, the reason it didn't work is because I needed the AC_LIBTOOL_DLOPEN macro defined. With this added, all seems to work well. Is this right/wrong? If right, why? I saw this when trying to link with the Winsock2 library (-lws2_32) before now and decided to try and update libtool from 1.4.x to 1.5.18. It worked perfectly especially now I make use of the automatic import/export feature in gcc, however, this doesn't work for libpq? This was a problem with environment and different versions of libtool, etc. My mistake :) The only other detail I have noticed about libpq.dll is that the file format is pe-i386 and my libraries and the Winsock2 library is of format pei-i386. Does this have an impact on my problem? I am interested in the differences between a pe-i386 format and a pei- i386 are, plus if there are any issues mixing and matching libraries and executables of different types? So basically, I have got it all running. The only other issue I had was using libltdl within a library. For some reason, the symbols were not exported properly so I couldn't link with it. The symbols that were in the library were specifically libltdl functions? -- Regards, Martyn ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Link Problem on Windows
Hi Martyn, * Martyn Russell wrote on Tue, Jun 07, 2005 at 12:52:44PM CEST: On Thu, 2005-06-02 at 16:13 +0100, Martyn Russell wrote: I am currently having problems linking in libpq (Postgres client front end) from PostgreSQL 8.0.2. I downloaded the source and installed it under MSYS/MinGW (to /usr/local). The .dll and the .a are in /usr/local/pgsql/lib. I have tried using -L/usr/local/pgsql/lib -lpq but it fails miserably, I get the following: *** Warning: linker path does not have real file for library -lpq. *snip* *** using a file magic. Last file checked: C:/msys/1.0/local/pgsql/lib/libpq.dll *snip* OK, just thought I would post my progress on this. Great! Basically, the reason it didn't work is because I needed the AC_LIBTOOL_DLOPEN macro defined. With this added, all seems to work well. Is this right/wrong? If right, why? Docs state that you need this (for 1.5.18). Does that suffice for an answer? For newer branches you should add the `dlopen' option to LT_INIT: LT_INIT([dlopen]) I saw this when trying to link with the Winsock2 library (-lws2_32) before now and decided to try and update libtool from 1.4.x to 1.5.18. It worked perfectly especially now I make use of the automatic import/export feature in gcc, however, this doesn't work for libpq? This was a problem with environment and different versions of libtool, etc. My mistake :) So that works now? The only other detail I have noticed about libpq.dll is that the file format is pe-i386 and my libraries and the Winsock2 library is of format pei-i386. Does this have an impact on my problem? I am interested in the differences between a pe-i386 format and a pei- i386 are, plus if there are any issues mixing and matching libraries and executables of different types? Should be documented with GNU ld. I haven't had the chance to dive in there yet, though. So basically, I have got it all running. The only other issue I had was using libltdl within a library. For some reason, the symbols were not exported properly so I couldn't link with it. The symbols that were in the library were specifically libltdl functions? Using libltdl from within a library is supported only starting with branch-2-0, not with branch-1-5. There are known problems that manifest themselves (at least) on MinGW, though (less on cygwin). The recent archives of this and the libtool-patches mailing list have details. Work on this is always welcome. :) Cheers, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Link Problem on Windows
Hi Martyn, Please keep the mailing list copied, thank you. * Martyn Russell wrote on Tue, Jun 07, 2005 at 01:58:18PM CEST: On Tue, 2005-06-07 at 13:33 +0200, Ralf Wildenhues wrote: Basically, the reason it didn't work is because I needed the AC_LIBTOOL_DLOPEN macro defined. With this added, all seems to work well. Is this right/wrong? If right, why? Docs state that you need this (for 1.5.18). Does that suffice for an answer? For newer branches you should add the `dlopen' option to LT_INIT: LT_INIT([dlopen]) Mmm, not seen this used before in any configure script, is this a specific libtool function added to m4 scripts like acinclude.m4? Oh, I should have explained a little more verbosely: For 1.5.x, you put AC_LIBTOOL_DLOPEN AC_PROG_LIBTOOL in your configure.ac (or whereever else they are now). For branch-2-0, all the macro naming has been cleaned up an unified. Instead of above two lines you now write LT_INIT([dlopen]) If you has used only the AC_PROG_LIBTOOL line, running `autoupdate' should have changed that automatically to LT_INIT. autoupdate cannot do the second step alone, it will warn you that you need to do that yourself. OK? This was a problem with environment and different versions of libtool, etc. My mistake :) So that works now? End to end, all the software is working perfectly, thanks. Great. Cheers, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
