Re: DLL creation and static libs
On 2 November 2010 13:26, Charles Wilson cyg...@cwilson.fastmail.fm wrote: On 11/2/2010 2:14 AM, Ralf Wildenhues wrote: ... the problem is there are TWO different libuuid's. There's the one that is part of the win32 api, and simply contains a number of static objects that represent UUIDs of elements of the Windows OS. [1] Then, there's the unix-derived one that provides routines for *generating* new UUIDs. [2] I thought of the nm tool. It could be used to identify which library is which, although AFAIK, it can't be used to generally identify libraries that contain data only. Is that correct? Matej ___ http://lists.gnu.org/mailman/listinfo/libtool
DLL creation and static libs
Hello, I have came across a libtool issue that complicates my life quite much. The essence of the problem is that libtool refuses to make a DLL if it is supposed to link a static library into the DLL. I have learned that this is a good assumption since the majority static libs don't contain PIC code, which would not work at all in the library. However, a DLL of a project that I work on and that I would like to cross-compile using mingw32 depends on libuuid.a, which is a static library. This most likely happens to people from time to time, see the link below. http://www.linuxquestions.org/questions/programming-9/libtool-problems-building-a-shared-library-790616/ For instance, I have encountered it because the mingw32 libregex (from the gnuwin project) currently depends on it. The trouble is that in this very case, it is OK to link with libuuid.a, because it contains data only. However libtool doesn't want to link with it no matter what. The situation is described in more detail in the link below by people who understand the stuff more: http://mingw-users.1079350.n2.nabble.com/undefined-ref-of-win32-function-with-mingw32msvc-td1089772.html So now the question is: What to do now? Maybe the mingw project is wrong? Or maybe it can be checked somehow whether a static library contains data only so it can be linked without problems? I also saw that Vincento Tori got involved in a similar issue, maybe he discovered something and forgot to tell us? :-) Matej ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: libtool versioning
I'm trying to understand the libtool current:revision:age versioning scheme. I think I understand how it works, but I noticed that filename of the shared library seems to get different numbers (current-age.age.revision). Is that expected? The filename generation is dependent on the OS. It is usually best not to pay any attention to the filenames at all unless you are switching from some other existing numbering scheme and need to avoid a collision. I keep these notes in my configure script (taken from various libtool related documentation) so that I remember how things work: If I have understood correctly, the whole LTversion stuff has only one purpose - to inform users what have they installed. You can't tell to libtool like link only with libfoo of LTversion = 5 or something like that, neither you can read the version using an AC macro or libtool itself. So the whole LTversion concept looks quite attractive, but, unfortunatelly, not so useful. If this is correct, I could try some doc patch describing the actual importance of LTversion stuff. Regards, Matěj ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Extend libtool dll namespaces for mingw-w64
On Tue, 2010-01-26 at 23:26 +0800, JonY wrote: ... I suggest the following naming scheme. mingw.org:libname-major.dll (unchanged) Cygwin: cygname-major.dll (unchanged) mingw-w64(64):lib64name-major.dll mingw-w64(32):lib32name-major.dll libtool should also check if GCC -m32 or -m64 is used, and select the proper namespace accordingly (mingw-w64 GCC can do multilib). Comments? AFAIK if you use automake, you have to have something like the following line in Makefile.am: lib_LTLIBRARIES = libfoo.la This means that the 'lib' prefix doesn't actually come from mingw, but from your automake setup, right? In order to be able to change the library name in a smarter way, something like lib_LTLIBRARIES = @lib...@foo.la # LIBrary PREfix would be needed, am I right? The LIBPRE value would be determined by the configure script. Or am I wrong at some point? This should allow some library name modifications as proposed here. What I would like to see one day though is that I am able to produce a library named foo.dll instead of libfoo.dll without any workarounds. That lib prefix tends to scare Windows users, but I am sure you know that too :-) I was not aware of possible conflicts that were mentioned here though. ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Extend libtool dll namespaces for mingw-w64
On Wed, 2010-01-27 at 22:19 +0100, Peter Rosin wrote: Den 2010-01-27 20:54 skrev Matěj Týč: On Tue, 2010-01-26 at 23:26 +0800, JonY wrote: ... I suggest the following naming scheme. mingw.org: libname-major.dll (unchanged) Cygwin:cygname-major.dll (unchanged) mingw-w64(64): lib64name-major.dll mingw-w64(32): lib32name-major.dll libtool should also check if GCC -m32 or -m64 is used, and select the proper namespace accordingly (mingw-w64 GCC can do multilib). Comments? AFAIK if you use automake, you have to have something like the following line in Makefile.am: lib_LTLIBRARIES = libfoo.la This means that the 'lib' prefix doesn't actually come from mingw, but from your automake setup, right? ... You are mistaken. The lib prefix on the dll files is coming from the libtool variable $libname_spec. It is typically set to something like this: # Format of library name prefix. libname_spec=lib\$name Which is then warped on Cygwin by another libtool variable, namely $soname_spec which has a sed -e s/^lib/cyg/ in it. A similar tweak is needed to implement this for mingw-w64. Cheers, Peter Wow, this is interesting. I remember that one guy asked about the dll prefix and he has been advised to strip the prefix from the library name and add the '-module' flag to libtool in order to silence complaints. Actually, here it is: http://lists.gnu.org/archive/html/libtool/2007-04/msg00022.html http://lists.gnu.org/archive/html/libtool/2007-05/msg1.html So how it is? Is there a another, more correct solution to Bob's challenge? ___ http://lists.gnu.org/mailman/listinfo/libtool
pthreads infection
Hello, if I link to a library that uses pthreads (for example OpenEXR suggests the -pthreads LDFLAG -- taken from OpenEXR.pc pkg-config file), I can see that unlike library dependencies this dependency propagates further like some disease. Even if my product is a library or a module, not only that I have to provide the -pthreads LDFLAG during (library / module) compilation, but the app (that uses the produced library / opens that module) also has to be linked with the -pthread LDFLAG. The problem is that libtool doesn't seem to discover this problematic dependency and forgets to add the appropriate flag to the app that is known to use the library (that uses the -pthreads flag) when the library's .la file is present. Is this a bug that can be fixed, or does it have some normal solution? However, in a case of a module, there is generally no way that I can determine whether my app will have to open such pthreads-infected module. Therefore I could add the -pthread flag as some prevenive measure, but it is not quite portable, is it? I have took a look at gnulib and AFAIK it doesn't address this issue either. I think that I am supposed to use mthreads on Windows or something like that. Any suggestions? Regards, Matej ___ http://lists.gnu.org/mailman/listinfo/libtool
lt_dlerror 'file not found' bug
Hello, this is ltdl-related, especially related to the case when you try to open an invalid module without knowing that it actually is invalid. The story is that if you try to lt_dlopen a module that can't be dlopened (for example when it has unsatisfied dependencies), the lt_dlopen function will return null module handle. If you want to know where is the problem, you usually call the lt_dlerror() function immediatelly afterwards and examine the error string. The problem is that you always get the 'file not found' message. But it is not the case: If you manage to fix the error in your module, you can experience that it becomes magically dlopenable, although all files remain on the same place as before. This is caused by lt_dlopen's behavior: It may not know what file to actually open. Even if you pass the module's .la file, which should be by intuition the best solution, it attempts to dlopen all sorts of files, some of them may even not be present. Therefore if one attempt fails, lt_dlopen tries the next one. And this happens even if the reason of the failiure was not the inability to locate the file. If everything fails, an error is set. Obviously it is the error from the last attempt, that usually is that 'file not found' case. The error that matters is therefore overwritten by every subsequent error. I have briefly tested the git version, the bug is still there. I would like to contribute to fix this bug. Could you please provide me with advice here and there? What I have thought of is stopping any attempt to open any new module filename if the previous attempt has failed for another reason that because the file wasn't there. Do you think this is a good assumption? Regards, Matej ___ http://lists.gnu.org/mailman/listinfo/libtool
ltdl - how to export from modules
Hello, if you want to lt_dlsym functions from your modules, how do you do that? If you write Windows libraries, you have to dllexport stuff, however GCC 4 supports the same feature, there you have to use visibility(default) stuff. There is something about this in the libtool manual (section 11.2): That is if I prepend something_LTX_ before the symbol name, the symbol becomes 'external'. However I have the impression that this is an extra layer and that I still have to take care of visibility like I have to when dealing with shared libraries. Probably with one exception, Windows uses dllimport to use shared lib functions, but this doesn't make sense to me in case of modules... Is that right? If yes, maybe it could be mentioned in the manual. Regards, Matej ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: libtool searches '.' by default (was: unexpected emergence of --whole-archive)
It seems that the current build directory is implicitly passed as an -L. flag to the libtool-supervised linker No. Well, first off, until this message of yours, I didn't know that /home/bubla/projects/devil_modular/lib/ was the current build directory. Hmm. This line in ltmain.m4sh:func_mode_link is suspicious: lib_search_path=`pwd` You are right. Doing as you have suggested eliminates the trouble. The trouble can be actually quite frustrating if you use a convenience library that has the same name as a system library you would like to link to. The first build is somehow OK, but rebuilds fail. It was added sometime during the ild-branch; details seem to be lost in the git history, so I can't tell whether it was added to fix some bug or so (but I'd have some qualms to remove it without further investigation). Does replacing it with lib_search_path= fix the issue for you? Yes, sir! Thank you, Matej ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: unexpected emergence of --whole-archive
Maybe one question towards libtool maintainers is left: Is that detection of lib/libjpeg.la a desired behavior? I just pass -ljpeg as an LDFLAGG, not as a LIBADD library... Yes, it is. It is also intentional that .la files are installed (of course for non-convenience archives only), and those installed libfoo.la files are taken into account when -lfoo is passed. Well, this is not about detecting of installed .la files, but about rather unexpected detection of .la files located in the build directory (that is also named 'lib'). It seems that the current build directory is implicitly passed as an -L. flag to the libtool-supervised linker ___ http://lists.gnu.org/mailman/listinfo/libtool
unexpected emergence of --whole-archive
Hello, I use autotools libtool to make a library. That library consists of the main shared library file and a set of dynamically loadable modules. Those modules depend on external shared libraries. I have written configure.ac and Makefile.am that are quite complex and some things are generated during the configure time (it is an image loading library supporting quite a lot of formats). So I can't post stuff here, there is too much of it. The problem is: During the build of libraries, some modules refuse to build. The cause is, however, absolutely strange. During the 'make' phase, the following happens: /bin/sh ../libtool --tag=CC --mode=link gcc -DNOINLINE -Wextra -g -O0 -module -lpng12 -o png.la -rpath /usr/local/lib/IL png_la-il_png.lo -lm -lz results in: libtool: link: gcc -shared .libs/png_la-il_png.o -lpng12 -lm -lz -Wl,-soname -Wl,png.so.0 -o .libs/png.so.0.0.0 That is OK. However: /bin/sh ../libtool --tag=CC --mode=link gcc -DNOINLINE -Wextra -g -O0 -module -ljpeg -o jpeg.la -rpath /usr/local/lib/IL jpeg_la-il_jpeg.lo -lm -lz results in: libtool: link: gcc -shared .libs/jpeg_la-il_jpeg.o -Wl,--whole-archive /home/bubla/projects/devil_modular/lib/.libs/libjpeg.a -Wl,--no-whole-archive -ljpeg -lm -lz-Wl,-soname -Wl,jpeg.so.0 -o .libs/jpeg.so.0.0.0 and consequently an error occurs: gcc: /home/bubla/projects/devil_modular/lib/.libs/libjpeg.a: No such file or directory To have something to start with, you have an idea where does that -Wl,--whole-archive bla bla -Wl,--no-whole-archive section come from? Regards, Matej ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: unexpected emergence of --whole-archive
/bin/sh ../libtool --tag=CC --mode=link gcc -DNOINLINE -Wextra -g -O0 -module -lpng12 -o png.la -rpath /usr/local/lib/IL png_la-il_png.lo -lm -lz results in: libtool: link: gcc -shared .libs/png_la-il_png.o -lpng12 -lm -lz -Wl,-soname -Wl,png.so.0 -o .libs/png.so.0.0.0 That is OK. However: /bin/sh ../libtool --tag=CC --mode=link gcc -DNOINLINE -Wextra -g -O0 -module -ljpeg -o jpeg.la -rpath /usr/local/lib/IL jpeg_la-il_jpeg.lo -lm -lz results in: libtool: link: gcc -shared .libs/jpeg_la-il_jpeg.o -Wl,--whole-archive /home/bubla/projects/devil_modular/lib/.libs/libjpeg.a -Wl,--no-whole-archive -ljpeg -lm -lz-Wl,-soname -Wl,jpeg.so.0 -o .libs/jpeg.so.0.0.0 and consequently an error occurs: gcc: /home/bubla/projects/devil_modular/lib/.libs/libjpeg.a: No such file or directory To have something to start with, you have an idea where does that -Wl,--whole-archive bla bla -Wl,--no-whole-archive section come from? /home/bubla/projects/devil_modular/lib/libjpeg.la is a libtool convenience library (or at least libtool thinks it is). How was it created? What is the Makefile.am rule for it? The funny and mysterious thing about this is that it should not be created. Actually, it is not created, but it is somehow required in the linking phase. The rules to create the 'png' and 'jpeg' modules are exactly the same in the Makefile.am! I can't understand at all how come that it is different in the end... It would be good to know what makes libtool to come up with that idea about the convenience library... Also notice that libtool demands libjpeg.a, not libjpeg.la Matej ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: unexpected emergence of --whole-archive
In the directory /home/bubla/projects/devil_modular/lib/ you have a libjpeg.la file. This is not the jpeg module that you are creating, it is a different library. libtool finds this when you pass -ljpeg (not sure why, as there is no -L flag for that directory). This libjpeg.la is a libtool created file that instructs libtool that the libjpeg.a sitting next to it is a libtool convenience archive. I am really impressed, you are right! That file was there, but it was not created during that build, it is from earlier. The library has an option to build stuff as modules or to compile it in using convenience libraries. Removing those has fixed the problem. I am really grateful that you have helped me, many thanks, Peter! Maybe one question towards libtool maintainers is left: Is that detection of lib/libjpeg.la a desired behavior? I just pass -ljpeg as an LDFLAGG, not as a LIBADD library... Regards, Matej ___ http://lists.gnu.org/mailman/listinfo/libtool
ltdl weirdness
Hello all, I am using libltdl in my project and I experience some unexpected things. First of all, if I have some undefined references in my module, the module can't be loaded using lt_dlopen neither using its ext variant. The reason for that is stated as could not find the file, but this is not the case. If I correct those undefined references, everything statrts to work. BTW the 'dltest' tool had helped me, although it is a pity that it doesn't support loading symbols from executables that would load the module. Next, if the executable is compiled with -export-dynamic, things that were compiled in really provide symbols that would be missing in the module. However, things that were linked in as external libs don't seem to be exported. Is this expected behaviour? However, there is a difference between having nothing and between having linked external symbols in executable compiled using -export-dynamic flag -- the first case results in the inability to open the module (see the first problem), whereas the latter results in runtime error. Any suggestions regarding good practices? Regards, Matej ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: how to link with libtool?
Yes, it may be a good idea if somebody wrote this. It should probably depend on LT_OUTPUT. OTOH, the havelib module from gnulib already provides quite a bit of functionality in this area. OK, but what should I tell to the library users? Using gnulib is quite troublesome since it does not have proper documentation and usage of the library would become too complicated for a casual programmer. And I don't like pkg-config since it breaks cross-compilation... So if I understand correctly, do I have to check for existence of /usr/lib/libfoo.la and then write maude_LDADD = /usr/lib/libfoo.la in my Makefile.am? ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: library versioning
Thank you for your reply, Ralf This is not possible, in general. It has nothing much to do with libtool either, because typically it's just the system semantics that allow for only one unversioned soname symlink. OK, but an easy check whether I can safely link with the lib would be nice, too. Of course, if you don't have to be able to have multiple versions installed concurrently, then all you do is use a configure test like AC_CHECK_LIB or sisters with the latest-added symbol that you need, or a self-written link test if the latest needed API isn't distinguishable by function symbol alone. Another point of having a AC_CHECK_LTLIB - like macro would be a possibility to check whether the version of the library is OK. Sometimes it is not possible to use AC_CHECK_LIB to check whether a function is in the library (due to calling convention). Well, I just wonder what is the sense of the libtool's versioning system since it can't be used by library users :-) Regards, Matej ___ http://lists.gnu.org/mailman/listinfo/libtool
how to link with libtool?
Hello, I have a library that has its .la file in the right place. The question is: What should I do in the autotools setup so that libtool takes over the compilation, discovers the .la file and passes additional options to the linker so that the linking doesn't fail? Having AC_PROG_LIBTOOL in the configure.ac is not enough... What about having a AC_CHECK_LTLIB macro? This would be good to check for libtool libs first and for pkg-config configuration only if someone has taken the .la files away (some distros do that) What do you think of this? Matej ___ http://lists.gnu.org/mailman/listinfo/libtool
library versioning
Hello, libtool has a nice way how to version libraries. However, how do I tell to the linker that my app has to link with the library that supports interface x? This seems as a very trivial question, but I haven't found the answer in the manual, is that possible? Regards, Matej ___ http://lists.gnu.org/mailman/listinfo/libtool
DLL howto
Hi all, I am seeking a howto regarding making DLLs for Windows. I have found some information about DLLs here http://www.freesoftwaremagazine.com/books/agaal/building_shared_libraries_once_using_autotools some in the goat book http://www.ensta.fr/~diam/dev/online/autoconf/autobook/autobook_252.html and something is in the libtool manual as well. I only fear that the goat book is seriously outdated and I don't understand everything in the libtool manual (page 28,‘win32-dll’) since I am not very familiar with the background. What is the meaning of exported with __declspec(dllexport) and imported with __declspec(dllimport)? Maybe I am missing something, but I think it should be reflected more in the libtool manual. I would like to improve that if I understand the problem. Regards, Matej ___ http://lists.gnu.org/mailman/listinfo/libtool
static part of a shared library
Greetings to all of you, I would like to use libtool with a multiplatform library that has some complicated structure (ASM routines, some 'main' function hijacking etc.) I think that libtool may be the right tool for managing the build and the linking afterwards. So imagine this situation: You want to compile a (shared) library. And you also have very good reasons for requiring that a part of the library is build as a static library ONLY and that the rest depends on it. So once more: 1. I want to build a static library libfoo_unsharable out of some sources 2. And I want to build a (shared) library libfoo. 3. Finally, whenever I link with either static or shared version of libfoo, I want libtool to link with libfoo_unsharable automatically. And the questions are: I use automake. What to write there 1. What LDFLAGS disable building of shared library from some sources? Does the -static flag ensure that shared library won't be build no matter what? :-) 2. How to tell to libtool to link with libfoo_unsharable every time you link with libfoo? When I have examined the libfoo.la, there was no mention about libfoo_unsharable there... Any ideas ? Regards, Matej ___ http://lists.gnu.org/mailman/listinfo/libtool
