Re: [RFC] w32 and Libtool.
Den 2010-11-01 17:31 skrev Ralf Wildenhues: Hi Peter, * Peter Rosin wrote on Mon, Nov 01, 2010 at 10:12:01AM CET: For PDF and DVI, the text looks like this: With contemporary GNU tools, auto-import often saves the day, but see the GNU ld documentation and its ‘--enable-auto-import’ option for some corner cases when it does not (see Section “Options specific to i386 PE targets” in Using ld, the GNU linker). But the link in the PDF document is only useful to open the ld.pdf file, I'm not successful in getting the link to take me further than that no matter how I feebly try to put it. Could you report this bit to bug-texinfo, please? It turned out to be a problem with the ld.pdf file. With a better ld.pdf I get to the same spot as with html (i.e. the start of the Command Line Options section). Cheers, Peter
Re: ltmain.sh patch: -all-dynamic option
Ralf Wildenhues ralf.wildenh...@gmx.de writes: Hello Karl-Andre', * Karl-Andre' Skevik wrote on Sat, Oct 30, 2010 at 11:46:38AM CEST: I have an application that builds a library for use with LD_PRELOAD, which should only be built dynamically. I have used a modification like the one below to achieve this: *** ltmain.sh.orig Sat Oct 30 11:35:37 2010 --- ltmain.sh Sat Oct 30 11:37:50 2010 *** *** 5173,5178 --- 5173,5185 fi prefer_static_libs=yes ;; + -all-dynamic) + if test $build_libtool_libs = no; then + func_warning unable to build only dynamic libraries in this configuration + fi + build_old_libs=no + prefer_static_libs=no + ;; -static) if test -z $pic_flag test -n $link_static_flag; then dlopen_self=$dlopen_self_static Would it be possible to have this kind of functionality included in the official libtool distribution? Thanks for the report and patch. What does -all-dynamic bring you that either of the following won't? Hello, thank you for the feedback. - configure with --disable-static, The package also builds normal libraries that should be build both as static and dynamic, so this option can unfortunately not be used. - add --tag=disable-static to AM_LIBTOOLFLAGS or libfoo_la_LIBTOOLFLAGS. At least with libtool 1.5.26 this does not appear to have any effect, a static library still gets built and installed. Regards, Karl-Andre' Skevik Inferno Nettverk A/S
Re: ltmain.sh patch: -all-dynamic option
* Karl-Andre' Skevik wrote on Tue, Nov 02, 2010 at 09:26:33AM CET: Ralf Wildenhues writes: * Karl-Andre' Skevik wrote on Sat, Oct 30, 2010 at 11:46:38AM CEST: I have an application that builds a library for use with LD_PRELOAD, which should only be built dynamically. I have used a modification like the one below to achieve this: Thanks for the report and patch. What does -all-dynamic bring you that either of the following won't? - configure with --disable-static, The package also builds normal libraries that should be build both as static and dynamic, so this option can unfortunately not be used. OK. - add --tag=disable-static to AM_LIBTOOLFLAGS or libfoo_la_LIBTOOLFLAGS. At least with libtool 1.5.26 this does not appear to have any effect, a static library still gets built and installed. Libtool 1.5.26 is old, and the 1.5 branch not maintained any more. We have arrived at 2.4, please consider updating. That said, I *think* that this should have worked with 1.5.x already; but you need Automake = 1.10 for support of the *_LIBTOOLFLAGS special variables. I'm guessing that you have an older Automake, because the following minimal example gets me a libfoo that is not built statically. Please report whether it does for you, and if you get a static libfoo.a, please try to modify the example so it exposes the failure in your setup. Thanks, Ralf cat configure.ac \EOF AC_INIT([a], [1]) AM_INIT_AUTOMAKE([foreign]) AC_PROG_CC AC_PROG_LIBTOOL AC_CONFIG_FILES([Makefile]) AC_OUTPUT EOF cat Makefile.am \EOF lib_LTLIBRARIES = libfoo.la libfoo_la_LIBTOOLFLAGS = --tag=disable-static EOF : libfoo.c autoreconf -vi ./configure make make install
Re: DLL creation and static libs
Hello Matěj, * Matěj Týč wrote on Wed, Oct 27, 2010 at 10:44:25PM CEST: 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. [...] 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. Also, w32 COFF essentially doesn't produce different code for shared libraries. 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? No, I don't think so. Or maybe it can be checked somehow whether a static library contains data only so it can be linked without problems? Maybe that. Since libuuid seems to be fairly special, I don't have any problem with special-casing it (as we already do for -lc -lm and maybe a couple of other libraries). OTOH, if the w32 maintainers agree, then we can also give in and allow linking against static libraries plainly. I tried the trivial patch (set deplibs_check_method to pass_all) a while ago but that caused a number of test failures, so somebody would at least have to look into this issue. Thanks for the report, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: DLL creation and static libs
On 11/2/2010 2:14 AM, Ralf Wildenhues wrote: OTOH, if the w32 maintainers agree, then we can also give in and allow linking against static libraries plainly. I tried the trivial patch (set deplibs_check_method to pass_all) a while ago but that caused a number of test failures, so somebody would at least have to look into this issue. 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] [1] On cygwin this is /usr/lib/w32api/libuuid.a (On mingw, it's /usr/lib/libuuid.a). In both cases, it IS a static library, not an import library. [2] On cygwin, this is /usr/lib/libuuid.[a,dll.a]. To my knowledge, there is no corresponding element for mingw. So...the special casing is going to be pretty complex, because you don't want to treat cygwin's unix-derived /usr/lib/libuuid* differently than any other library, but mingw's /usr/lib/libuuid.a and cygwin's /usr/lib/w32api/libuuid.a would both need the special treatment. (FYI: we'd also need to add similar logic to binutils' ld, to special case the auto-export). -- Chuck ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: How to create only target shared library at place not ending in rpath?
Hello Ralf, I have few tens of projects which I need install into few tens of sysroots. Currently it's to slow in following cases: 1) libtool --mode=link create shared objects which I newer use. 2) each libtool --mode=install create same shared objects binaries for each sysroot. Currently I try to install into left dir and during installation I only copy precreated binaries. I think it's a hack, But have no other ides. Anyone have ideas to optimise it in right way? PS: creating static binaries is disabled. \\wbr Vitaly Chernooky On Mon, Nov 1, 2010 at 6:30 PM, Ralf Wildenhues ralf.wildenh...@gmx.de wrote: Hello Vitaly, * Vitaly V. Ch wrote on Mon, Nov 01, 2010 at 02:01:44PM CET: I'm try to speed up compilation of my project by removing overhead stages. Especially time of installation. Please also try to speed up communication for us by slowing down communication on your end of the mail writing: Please state your problem more clearly, so we don't have to ask what you meant. Thank you. Would you like to avoid building both static and shared libraries? Use --disable-static or --disable-shared at configure time. Would you like to speed up 'make install'? Use the newest Automake version, in case you're using a version older than 1.11 now. Would you like to not install some of the shared libraries you build, but still create them as shared rather than convenience archives? Use noinst_LTLIBRARIES but also pass '-rpath /nowhere' or so in libfoo_la_LDFLAGS. Hope that helps. Cheers, Ralf -- \\wbr Vitaly ___ http://lists.gnu.org/mailman/listinfo/libtool
