Next libtool release?
What happened to the release? Joakim
Add missing sysroot to library path ?
Has some variant of https://lists.gnu.org/archive/html/libtool-patches/2022-04/msg00010.html been discussed/considered ? Joakim
Re: Potential bugfix for bug#21455: Bug while cross-compiling multiple libtool-based packages ...
Ping ? On Sun, 2015-10-18 at 15:41 +0200, Joakim Tjernlund wrote: > While googling for a fix for bug#21455, > http://lists.gnu.org/archive/html/bug-libtool/2015-09/msg00012.html , > I came across: > > http://cgit.openembedded.org/cgit.cgi/openembedded/tree/recipes/libtool/libtool-2.4/use-sysroot-in-libpath > .patch?id=release-2010.12 > > This appear to be the correct fix for the error in bug 21455 > > Jocke ___ https://lists.gnu.org/mailman/listinfo/libtool
Potential bugfix for bug#21455: Bug while cross-compiling multiple libtool-based packages ...
While googling for a fix for bug#21455, http://lists.gnu.org/archive/html/bug-libtool/2015-09/msg00012.html , I came across: http://cgit.openembedded.org/cgit.cgi/openembedded/tree/recipes/libtool/libtool-2.4/use-sysroot-in-libpath.patch?id=release-2010.12 This appear to be the correct fix for the error in bug 21455 Jocke ___ https://lists.gnu.org/mailman/listinfo/libtool
libtool and sysroot
I noted that --with-sysroot=yes calls(=yes seems undocumented?) lt_sysroot=`$CC --print-sysroot 2/dev/null` Should not $CFLAGS be included here too as gcc may have its sysroot changed with --sysroot? Jocke ___ https://lists.gnu.org/mailman/listinfo/libtool
Re: silent installs
Ralf Wildenhues ralf.wildenh...@gmx.de wrote on 2010/01/31 08:38:38: [ moving to libtool@ from automake@; this is http://thread.gmane.org/gmane.comp.sysutils.automake.general/11347/focus=11374 this particular message is about whether the relinking warning and the warning about the need to --finish should be changed to be notices only, which would cause them to not be displayed with `libtool --silent' which implies that an Automake --enable-silent-rules build would not show them at `make install' time. ] If you additionally would like to not see output from libtool, pass LIBTOOLFLAGS=--silent I do so but still see those msgs. It just occurred to me that ltmain.sh could change those line from func_warning to func_verbose instead: My problem with that change is that, the relinking and finish really are information that some users need to know about. If you don't --finish, then your libraries won't be found by the runtime linker. If relinking happens as another user than the one who ran `make all', that is a problem to know about, too, because it can lead to problems with file ownership and directory write permission. But they are not errors so they should not be directed to stderr no matter what. Then one can argue if --silent should suppress these msgs too or not. So the question really is whether to make their life harder for making your life easier. Not really, I think autotools(including libtool) should support both the user trying to build some SW pkg he/she has downloaded and the developer who is working to improve the said pkg in his daliy work. I am in the latter group I'd like to know what other libtool people think about this, so feedback appreciated. Thanks, Ralf --- ltmain.sh (revision 57662) +++ ltmain.sh (working copy) @@ -2028,7 +2028,7 @@ relink_command=`$ECHO X$relink_command | $Xsed -e s...@inst_prefix_dir@%%` fi - func_warning relinking \`$file' + func_verbose relinking \`$file' func_show_eval $relink_command \ 'func_fatal_error error: relink \`$file'\'' with the above command before installing it' fi @@ -2269,7 +2269,7 @@ done test -n $future_libdirs \ - func_warning remember to run \`$progname --finish$future_libdirs' + func_verbose remember to run \`$progname --finish$future_libdirs' if test -n $current_libdirs; then # Maybe just do a dry run. ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: silent installs
Peter Johansson troj...@gmail.com wrote on 2010/01/31 16:28:52: On 1/31/10 6:10 AM, Joakim Tjernlund wrote: Ralf Wildenhuesralf.wildenh...@gmx.de wrote on 2010/01/31 08:38:38: My problem with that change is that, the relinking and finish really are information that some users need to know about. If you don't --finish, then your libraries won't be found by the runtime linker. If relinking happens as another user than the one who ran `make all', that is a problem to know about, too, because it can lead to problems with file ownership and directory write permission. But they are not errors so they should not be directed to stderr no matter what. Then one can argue if --silent should suppress these msgs too or not. Moving these messages to stdout would have the positive side effect that `make distcheck /dev/null' would become silent. That would be nice but is not worth it, if it means users miss the --finsih warning and end up sending bug reports to me about runtime errors. There has to be some middle ground here. If the user does /dev/null then he in trouble anyway. Why would he do that in the first place? And what if he does /dev/null 21 too? If the user really feels that he needs to use /dev/null, then perhaps there is something else that is wrong such as too much output in the first place? Jocke ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: silent installs
Bob Friesenhahn bfrie...@simple.dallas.tx.us wrote on 2010/01/31 18:23:30: On Sun, 31 Jan 2010, Ralf Wildenhues wrote: So the question really is whether to make their life harder for making your life easier. I'd like to know what other libtool people think about this, so feedback appreciated. I think that some people are hypersensitive to seeing build text and that changes to behavior should be well-reasoned and based on the typical user/developer rather than a hypersensitive one. In the USA we call this using community standards. The install step is one of the most dangerous things that I do to my system and so I often do 'make -n install' and study what is going on before doing the actual 'make install'. The thought of requesting a silent install has never crossed my mind before. Sort of makes sense when you install to your host but when install into a DESTDIR as a normal user to later transfer the whole image to another system (embedded in my case) it isn't such a big deal. ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: [PATCH 0/2] Re: ifdef expessions in Makefile.am
bonz...@gnu.org wrote on 22/12/2009 09:16:59: From: Paolo Bonzini bonz...@gnu.org Here is where I was at. After that it was not immediate how to use a tag-dependent cache variable. Strictly speaking however using a cache variable is not needed to make the PIC test overridable. The patch is quite risky though. Paolo Paolo Bonzini (2): split -Wl test extract static flag detection hmm, looking into the patch I don't see how this lets me replace -fPIC with -fpic. Maybe I am missing something? Jocke
Re: relinking and finish warnings
Ralf Wildenhues ralf.wildenh...@gmx.de wrote on 16/12/2009 22:56:44: From: Ralf Wildenhues ralf.wildenh...@gmx.de To: Joakim Tjernlund joakim.tjernl...@transmode.se Cc: libtool@gnu.org Date: 16/12/2009 22:56 Subject: Re: relinking and finish warnings Hello Joakim, * Joakim Tjernlund wrote on Wed, Dec 16, 2009 at 06:15:53PM CET: If I specify a dependency lib like this: libucsiif_la_LIBADD = $(top_builddir)/ne/upc_uci_if/libuciif.la I get a relink warning: The warning should be a note. The note is necessary because users are otherwise likely surprised that the compiler/linker is run upon 'make install'. But I do like this instead: libucsiif_la_LIBADD = $(DESTDIR)$(libdir)/libuciif.so That's bogus, and will be wrong when you don't have a preinstalled library there. Also, how do i get rid of the remember to run `libtool --finish warning? You don't, that warning is not bogus. If you don't run libtool --finish yourself (when the libraries appear in their final location), it may be that the installed libraries are not usable before the next reboot (at which time systems typically run ldconfig). It just hit me that I failed to tell you I am using --silent and when doing that I don't think I should have to see these warnings as these are really not a warning, just a note. I would expect both AM_LIBTOOLFLAGS=--silent and LIBTOOLFLAGS=--silent suppress both of them. Jocke ___ http://lists.gnu.org/mailman/listinfo/libtool
libtool changes argv[0]
Now that I am using libtool's .la objects when build our apps we notice that the executables in the build tree becomes a script that run the binary form the .libs subdir. This has the side effect that out apps notices a change in argv[0] when we run them from within the build tree. Previously argv[0] was x/y/z, now it becomes x/y/.libs/z and our apps does not like that. Is it possible to do something about the change of argv[0]? libtool version 2.2.6b, gentoo Jocke ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: relinking and finish warnings
Ralf Wildenhues ralf.wildenh...@gmx.de wrote on 16/12/2009 22:56:44: From: Ralf Wildenhues ralf.wildenh...@gmx.de To: Joakim Tjernlund joakim.tjernl...@transmode.se Cc: libtool@gnu.org Date: 16/12/2009 22:56 Subject: Re: relinking and finish warnings Hello Joakim, * Joakim Tjernlund wrote on Wed, Dec 16, 2009 at 06:15:53PM CET: If I specify a dependency lib like this: libucsiif_la_LIBADD = $(top_builddir)/ne/upc_uci_if/libuciif.la I get a relink warning: The warning should be a note. The note is necessary because users are otherwise likely surprised that the compiler/linker is run upon 'make install'. But I do like this instead: libucsiif_la_LIBADD = $(DESTDIR)$(libdir)/libuciif.so That's bogus, and will be wrong when you don't have a preinstalled library there. Also, how do i get rid of the remember to run `libtool --finish warning? You don't, that warning is not bogus. If you don't run libtool --finish yourself (when the libraries appear in their final location), it may be that the installed libraries are not usable before the next reboot (at which time systems typically run ldconfig). OK, then I will go back to using prefix=$(DESTDIR)/opt/appl/xxx instead. I have noticed though that one should be able to hardcode rpath but I haven't figured out how to do that in configure/configure.ac, any pointers? Jocke ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: lib seach path
Ralf Wildenhues ralf.wildenh...@gmx.de wrote on 14/12/2009 19:52:54: * Joakim Tjernlund wrote on Mon, Dec 14, 2009 at 09:42:51AM CET: How do I add -static on a per lib basis? Currently there is no way to do so, but it is a TODO item and a proposed patch to add this functionality (search for 'per-deplib static'). For I see. Searched and found a msg that said you added this support in CVS in 2006. Has there not been a libtool release since then? in-tree libraries you could work around it by creating another variant of the library, with --tag=disable-shared added to its *_LIBTOOLFLAGS. hmm, that will introduce some churn in the make files. Using the .a libs directly does not work at all? I am using GNU/Linux if that matters. Note that none of the other deplibs should depend upon the shared version of the library you're linking statically. Cheers, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: lib seach path
Ralf Wildenhues ralf.wildenh...@gmx.de wrote on 14/12/2009 07:46:30: * Joakim Tjernlund wrote on Sun, Dec 13, 2009 at 12:04:23PM CET: Ralf Wildenhues wrote on 13/12/2009 11:14:58: For dependencies on libraries within the build tree, prefer relative file references over link flags; i.e., write ../lib/libfoo.la rather than -L../lib -lfoo That way, automake (which I assume you're using) will know to rebuild the output when libfoo changes. I am using automake. I didn't know automake didn't handle -lfoo dependency wise I hope ../lib/libfoo.a works though because some apps wants the static lib even though there is a shared one too? Add -static to link flags for that. Don't refer to files below .libs. How do I add -static on a per lib basis? I got libs such as: xxx_LDADD += $(top_builddir)/ne/cp_hw_if/libcphwif.a xxx_LDADD += $(top_builddir)/ne/nlib_lib_if/libnlib_lib_if.a xxx_LDADD += ../../alib_tsi_if/libtsiif.la xxx_LDADD += -lcsif xxx_LDADD += -liciif xxx_LDADD += -lteif (I note that the -l should be changed to .la) The two first libs should always be static even though there my be a shared version too. Jocke ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: lib seach path
Ralf Wildenhues ralf.wildenh...@gmx.de wrote on 13/12/2009 11:14:58: From: Ralf Wildenhues ralf.wildenh...@gmx.de To: Joakim Tjernlund joakim.tjernl...@transmode.se Cc: libtool@gnu.org Date: 13/12/2009 11:15 Subject: Re: lib seach path * Joakim Tjernlund wrote on Sat, Dec 12, 2009 at 04:33:49PM CET: We have this big directory structure which contains both apps and libs. The apps needs lots of libs that are scattered in various sub dirs. It is rather messy to add lots -LDIR options to apps linking stage. For dependencies on libraries within the build tree, prefer relative file references over link flags; i.e., write ../lib/libfoo.la rather than -L../lib -lfoo That way, automake (which I assume you're using) will know to rebuild the output when libfoo changes. I am using automake. I didn't know automake didn't handle -lfoo dependency wise I hope ../lib/libfoo.a works though because some apps wants the static lib even though there is a shared one too? Is there a way to tell libtool after it has built a lib to do a subinstall of the lib into some dir in the build tree so that one don't have to specify lots of -LDIR options, just to the one dir instead? No. OK, thanks ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: rpath
Ralf Wildenhues ralf.wildenh...@gmx.de wrote on 13/12/2009 11:18:31: * Joakim Tjernlund wrote on Sat, Dec 12, 2009 at 12:05:13PM CET: Ralf Corsepius wrote on 12/12/2009 07:20:05: The whole purpose of DESTDIR is being set at install-time and not to be AC_SUBST'ed anywhere. I.e. doing things like outlined above would contradict it's purpose. It doesn't seem to any other way as far as I can tell. We build our embedded SW with a different prefix each time to be able to separate the different builds alongside each other on the target. Each build is performed in a private DESTDIR which will vary depending on the actual arch and product. Setting DESTDIR via some script for one time builds works fine but for repeated build during development where one types make DESTDIR=... manually does not work so well. Ideally one should be able to set DESTDIR during configure but be able to override that by typing make DESTDIR=... Readoing your reply, I can only guess that you have misunderstood the purpose of DESTDIR completely and shouldn't be using it at all. Builds happen in build trees, which you can separate by just running configure from separate directories. Build trees have nothing to do Yes, I do this. with --prefix nor DESTDIR, which both revolve around install trees. In case you actually meant separate install trees, then use different values for --prefix. DESTDIR is only for things like I am building a package intended for /usr, but right now I am not the super-user, so `make install' will fail unless I temporarily divert the installation elsewhere so that I can still make a binary pacakge from the installation. Lets see, this is what I do: I am building for /opt/appl/ on the target using a build tree outside my sources: I want to install my apps/libs into a dir next to my build tree. Once everything is installed into the temporary install tree, I build a package from the files in the install tree into some sort of tar ball which I can transfer to the target and unpack it using the same tree structure as the install tree I just built. Currently I build with prefix that is $(build_tree)/opt/appl/ but then rpath will include the build_tree and that is not ideal. Perhaps there is a simpler way to set rpath? ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: rpath
Ralf Corsepius rc040...@freenet.de wrote on 12/12/2009 07:20:05: On 12/12/2009 12:57 AM, Ralf Wildenhues wrote: Hi Roumen, * Roumen Petrov wrote on Fri, Dec 11, 2009 at 09:36:54PM CET: Ralf Wildenhues wrote: AC_ARG_VAR([DESTDIR], [perform staged installation using DESTDIR]) This require makefiles generated by configure script to contain line like this one: destd...@destdir@ Right. If you wouldn't use Automake, you'd have to add that line yourself. The whole purpose of DESTDIR is being set at install-time and not to be AC_SUBST'ed anywhere. I.e. doing things like outlined above would contradict it's purpose. It doesn't seem to any other way as far as I can tell. We build our embedded SW with a different prefix each time to be able to separate the different builds alongside each other on the target. Each build is performed in a private DESTDIR which will vary depending on the actual arch and product. Setting DESTDIR via some script for one time builds works fine but for repeated build during development where one types make DESTDIR=... manually does not work so well. Ideally one should be able to set DESTDIR during configure but be able to override that by typing make DESTDIR=... Jocke ___ http://lists.gnu.org/mailman/listinfo/libtool
lib seach path
We have this big directory structure which contains both apps and libs. The apps needs lots of libs that are scattered in various sub dirs. It is rather messy to add lots -LDIR options to apps linking stage. Is there a way to tell libtool after it has built a lib to do a subinstall of the lib into some dir in the build tree so that one don't have to specify lots of -LDIR options, just to the one dir instead? Jocke ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: rpath
Ralf Wildenhues ralf.wildenh...@gmx.de wrote on 08/12/2009 20:13:13: From: Ralf Wildenhues ralf.wildenh...@gmx.de To: Joakim Tjernlund joakim.tjernl...@transmode.se Cc: libtool@gnu.org Date: 08/12/2009 20:14 Subject: Re: rpath Hello Joakim, * Joakim Tjernlund wrote on Tue, Dec 08, 2009 at 09:44:57AM CET: rpath gets set to /usr/local/lib but this is wrong for me. I am crosscompiling and point builddir to /some/dir and install into /some/dir/opt/x/y so I want rpath to point to /opt/x/y What controls rpath in libtool? ./configure --prefix=/opt/x/y make make install DESTDIR=/some/dir I getting back to this now that my libtool problem seem to be over. Pondring on DESTDIR, I wonder if there is a way to set a default DESTDIR at configure time so one does have to remember/type DESTDIR=.. at every make ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: rpath
Ralf Wildenhues ralf.wildenh...@gmx.de wrote on 10/12/2009 06:16:40: From: Ralf Wildenhues ralf.wildenh...@gmx.de To: Joakim Tjernlund joakim.tjernl...@transmode.se Cc: libtool@gnu.org Date: 10/12/2009 06:16 Subject: Re: rpath * Joakim Tjernlund wrote on Thu, Dec 10, 2009 at 12:50:14AM CET: Ralf Wildenhues wrote on 08/12/2009 20:13:13: ./configure --prefix=/opt/x/y make make install DESTDIR=/some/dir I getting back to this now that my libtool problem seem to be over. Pondring on DESTDIR, I wonder if there is a way to set a default DESTDIR at configure time so one does have to remember/type DESTDIR=.. at every make No, but you can just `export DESTDIR' in your environment. Yeah, but that isn't going to work in here, too easy to get wrong. I image I could add something to configure.ac that will allow me to set it at configure time? Not sure what would work though, any ideas? ___ http://lists.gnu.org/mailman/listinfo/libtool
rpath
rpath gets set to /usr/local/lib but this is wrong for me. I am crosscompiling and point builddir to /some/dir and install into /some/dir/opt/x/y so I want rpath to point to /opt/x/y What controls rpath in libtool? ___ http://lists.gnu.org/mailman/listinfo/libtool
new libtool version makes troble
We just upgraded libtool from 1.5.26 to 2.2.6 and our build broke. Our host requires 2.2.6 so keeping the old appears difficult. Even though we only run autoreconf manually in our project, the new libtool slipped into the project and the build broke. I can fix this by rerunning autoreconf -i -f in the current trunk but I cannot do that in already released SW. I had the impression that the libtool files installed by libtoolize -f should contain everything needed by libtool, that is, there would not be any dependencies of the host libtool. How can I prevent the new host libtool from slipping into the project? I would like to be able to run autoreconf even after upgrading the host libtool too, if possible. Jocke ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: new libtool version makes troble
Ralf Wildenhues ralf.wildenh...@gmx.de wrote on 08/12/2009 20:57:17: Hello Joakim, * Joakim Tjernlund wrote on Tue, Dec 08, 2009 at 03:23:39PM CET: We just upgraded libtool from 1.5.26 to 2.2.6 and our build broke. Our host requires 2.2.6 so keeping the old appears difficult. Even though we only run autoreconf manually in our project, the new libtool slipped into the project and the build broke. I can fix this by rerunning autoreconf -i -f in the current trunk but I cannot do that in already released SW. I had the impression that the libtool files installed by libtoolize -f should contain everything needed by libtool, that is, there would not be any dependencies of the host libtool. That is normally the case. Note that with Libtool 2.2.x, you can also use the following strategy: add AC_CONFIG_MACRO_DIR([m4]) to configure.ac, add ACLOCAL_AMFLAGS = -I m4 to Makefile.am, and run 'libtoolize -f --install' to have the Libtool macro files be copied into your tree. That way, aclocal.m4 will refer to them (rather than carry around a copy of their contents). How can I prevent the new host libtool from slipping into the project? I'm afraid I can't tell you with the information that you have given. Please show, not describe, how the host Libtool gets into your project; i.e., cut and paste the commands you enter and their output that shows something goes wrong. If your project is open source, don't refrain to link to a tarball or repository. Sorry for the somewhat vague description, but I have gotten somewhat further. I would like to be able to run autoreconf even after upgrading the host libtool too, if possible. Ah, if all you're after is to prevent autoreconf from running libtoolize, then try LIBTOOLIZE=true autoreconf I did add a m4 dir and copied the old libtool.m4 there. Now I can run configure and all is well but I think I might have misunderstood libtoolize. I figured libtoolize didn't install new files over the old ones unless -f was given. Is this how it is supposed to be? LIBTOOLIZE=true autoreconf appears to work, however I would like some way for autoreconf to pick this up automatically, if possible. I do have the impression that configure/make sometimes reruns libtoolize automatically, maybe I am just seeing things that aren't there? Another issue may be that aclocal fails to find the in-tree libtool macros, but finds some installed ones. That can typically be found out by passing --verbose to aclocal (passing --verbose to autoreconf will do that). What happens are that aclocal somehow triggers and install a new aclocal.m4 with the new libtool macros. The old ltmain.sh does not understand these and dies. Adding the m4 dir keeps the old macros and ltmain.sh works again Jocke ___ http://lists.gnu.org/mailman/listinfo/libtool
Only dyn libs
what do I write in Makefile.am to make libtool build dyn libs only? It seems like libtool always wants to build both static and dyn libs but I want to build some libs dynamic only to save build time/space. Jocke ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: -fpic support in libtool?
Ralf Wildenhues ralf.wildenh...@gmx.de wrote on 03/12/2009 08:20:22: From: Ralf Wildenhues ralf.wildenh...@gmx.de To: Joakim Tjernlund joakim.tjernl...@transmode.se Cc: Bob Friesenhahn bfrie...@simple.dallas.tx.us, libtool@gnu.org Date: 03/12/2009 08:20 Subject: Re: -fpic support in libtool? * Joakim Tjernlund wrote on Thu, Dec 03, 2009 at 08:06:25AM CET: Libtool can be influenced by the configure script by influencing this definition which gets output in the libtool script: # Additional compiler flags for building library objects. pic_flag= -fPIC -DPIC This seems to be controlled by the lt_prog_compiler_pic configure script variable. hmm, not sure what/if you are suggesting. Should I just try override the definition of pic_flag? In my configure.ac or somewhere else? You can probably get away with overriding lt_prog_compiler_pic, lt_prog_compiler_pic_CXX, ..., in configure.ac, when doing it *after* the AC_PROG_LIBTOOL aka LT_INIT invocation, and before either of AC_OUTPUT or LT_OUTPUT. However, this is not recommended, doing this will let configure test the wrong pic_flag (i.e., the one it sets rather than your override), and if this breaks now or in a later release you get to keep the pieces. We should probably change the code so that the override can be done before AC_PROG_LIBTOOL, so that at least -DPIC is added consistently, and that the compile test uses the right flag. Would it be possible to write something in acinclude.m4 that will override the -fPIC flag? Jocke ___ http://lists.gnu.org/mailman/listinfo/libtool
-fpic support in libtool?
Several years ago I asked libtool to support -fpic too but I don't see it in never libtool(s). I guess it isn't impl.? The simplest fix for adding -fpic I can come up with is doing sed -i 's/-fPIC/-fpic/' aclocal.m4 This is a bit clumsy as one can easily forget to do this when running aclocal manually. Is there a simpler way? One that will work both with 1.5 and 2.x versions of libtool? Jocke ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: -fpic support in libtool?
Bob Friesenhahn bfrie...@simple.dallas.tx.us wrote on 03/12/2009 03:27:55: On Thu, 3 Dec 2009, Joakim Tjernlund wrote: Several years ago I asked libtool to support -fpic too but I don't see it in never libtool(s). I guess it isn't impl.? The simplest fix for adding -fpic I can come up with is doing sed -i 's/-fPIC/-fpic/' aclocal.m4 This is a bit clumsy as one can easily forget to do this when running aclocal manually. Is there a simpler way? One that will work both with 1.5 and 2.x versions of libtool? How would libtool know which PIC variant will work? Note that some targets (e.g. PowerPC SPARC) offer many reduced PIC variants. These don't really work unless the developer is able to validate the application/library on many kinds of targets and somehow specify the correct variant which works for the target. We use auto*, libtool for an internal embedded project. This SW will always be built in a controlled env.(powerpc, linux). Since powerpc can deal with -fpic, I want to use it. Libtool can be influenced by the configure script by influencing this definition which gets output in the libtool script: # Additional compiler flags for building library objects. pic_flag= -fPIC -DPIC This seems to be controlled by the lt_prog_compiler_pic configure script variable. hmm, not sure what/if you are suggesting. Should I just try override the definition of pic_flag? In my configure.ac or somewhere else? Note that many compilers use something quite different from -fPIC to mean the same thing but don't accept -fpic so just substituting/inserting -fpic is likely to cause failure. Yes, but not in our case. ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: -fpic support in libtool?
Ralf Wildenhues ralf.wildenh...@gmx.de wrote on 03/12/2009 08:20:22: * Joakim Tjernlund wrote on Thu, Dec 03, 2009 at 08:06:25AM CET: Libtool can be influenced by the configure script by influencing this definition which gets output in the libtool script: # Additional compiler flags for building library objects. pic_flag= -fPIC -DPIC This seems to be controlled by the lt_prog_compiler_pic configure script variable. hmm, not sure what/if you are suggesting. Should I just try override the definition of pic_flag? In my configure.ac or somewhere else? You can probably get away with overriding lt_prog_compiler_pic, lt_prog_compiler_pic_CXX, ..., in configure.ac, when doing it *after* the AC_PROG_LIBTOOL aka LT_INIT invocation, and before either of AC_OUTPUT or LT_OUTPUT. However, this is not recommended, doing this will let configure test the wrong pic_flag (i.e., the one it sets rather than your override), and if this breaks now or in a later release you get to keep the pieces. Thanks, I will try that instead. We should probably change the code so that the override can be done before AC_PROG_LIBTOOL, so that at least -DPIC is added consistently, and that the compile test uses the right flag. This is far beyond my expertise. I do wish you would consider some way of specifying -fpic to libtool. It is useful for some arch's and embedded targets. Jocke ___ http://lists.gnu.org/mailman/listinfo/libtool
-fpic instead of -fPIC
Hi I want to use -fpic instead of -fPIC on a powerpc(linux) target since that generates smaller and faster libs. But I can't find out how to make libtool use -fpic. I don't want to do local changes to the installed libtool. build host is linux/x86. Any ideas? Jocke ___ http://lists.gnu.org/mailman/listinfo/libtool
RE: -fpic instead of -fPIC
Hi Joakim, * Joakim Tjernlund wrote on Mon, Jun 06, 2005 at 04:10:31PM CEST: I want to use -fpic instead of -fPIC on a powerpc(linux) target since that generates smaller and faster libs. But I can't find out how to make libtool use -fpic. I don't want to do local changes to the installed libtool. build host is linux/x86. The setting of pic_flag is hard-wired in AC_LIBTOOL_PROG_COMPILER_PIC in libtool.m4 now, if that's what you are looking for. OK, will look at that some more. I don't automake, autoconf and libtool very well so I need a liite guidance here. Can I just run aclocal and modify the generated aclocal.m4? I would then commit aclocal.m4 to CVS and use that when building our libs. Is there a better way? But how would you have Libtool find out when it will be used for large sources for which -fpic will fail? This is mainly for our own development of onboard SW for a embedded target and we want to save space. (Note I *could* imagine some kind of parametrization a la `-small-pic', but I'll tell you right away that the amount of possible breakage is huge, huge, and dangerous, and hard to find only after hours of compilation; and the resulting fights with users..) hmm, but in some cases it is justified. Think embedded products. Two questions to ponder before you think about -fpic: Have you measured the speed impact of -fpic vs -fPIC? Please show, I'm interested! Nope, but i did look at the libs with readelf -a and found that accesses to a global variables seems to generates a reloc per access to that global variable(why?) and that can quickly waste space. If the difference is noticeable: Have you slapped the library author with Drepper's dsohowto.pdf yet? If so, please share with us his/her reasoning to ignore it. :) Nope, not yet. Will have to slap myself and my team in that case :) I have read that doc and learned a lot from it. However even Drepper seems to like -fpic in one case: glibc for ppc is compiled with -fpic. PPC can handle big libs even with -fpic. Regards, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
RE: -fpic instead of -fPIC
Hi Ralf, thanks for your input Hi Joakim, * Joakim Tjernlund wrote on Mon, Jun 06, 2005 at 07:21:17PM CEST: * Joakim Tjernlund wrote on Mon, Jun 06, 2005 at 04:10:31PM CEST: I want to use -fpic instead of -fPIC on a powerpc(linux) target since that generates smaller and faster libs. But I can't find out how to make libtool use -fpic. I don't want to do local changes to the installed libtool. build host is linux/x86. The setting of pic_flag is hard-wired in AC_LIBTOOL_PROG_COMPILER_PIC in libtool.m4 now, if that's what you are looking for. OK, will look at that some more. I don't automake, autoconf and libtool very well so I need a liite guidance here. Can I just run aclocal and modify the generated aclocal.m4? I would then commit aclocal.m4 to CVS and use that when building our libs. Yes, you can do that. Just did that but aclocal.m4 got regenerated by the build. hmm, need to look some more at that Is there a better way? If you use recent Automake, it might be more favorable for you to create a subdir `m4' and put all the m4 macro files you need in there (libtool.m4, ...), and then put ACLOCAL_AMFLAGS = -I m4 in $top_srcdir/Makefile.am. Is 1.4-p6 recent enough? Seems so. I have copied libtool.m4 to my local m4 dir and modified it to: AC_MSG_RESULT([$_LT_AC_TAGVAR(lt_prog_compiler_pic, '-fpic')]) but so far no luck :( Just noticed another problem: All my libs are created without .so suffix. This is on a debian(prerelease of 3.1) Then you can just edit the files in m4/, but now it will be easier for you to update them when you want to. (You still need to make sure libtool.m4 and ltmain.sh are updated at the same time.) (At some point in the future, setting AC_CONFIG_MACRO_DIR([m4]) in configure.ac will also allow automatic updating of the files in m4/.) Still on configure.in :) But how would you have Libtool find out when it will be used for large sources for which -fpic will fail? This is mainly for our own development of onboard SW for a embedded target and we want to save space. OK, then it might make sense to do like above. Do you perchance build for a different system? For that it might make sense to think about setting pic_flag differently (for example if the usual memory of such an embedded target makes -fPIC obsolete anyway). pic_flag ? I was thinking of lt_prog_compiler_pic. I am crossbuilding from linux/x86 to linux/ppc. semtimes we build for linux/x86 to test. (Note I *could* imagine some kind of parametrization a la `-small-pic', but I'll tell you right away that the amount of possible breakage is huge, huge, and dangerous, and hard to find only after hours of compilation; and the resulting fights with users..) hmm, but in some cases it is justified. Think embedded products. Valid point. Two questions to ponder before you think about -fpic: Have you measured the speed impact of -fpic vs -fPIC? Please show, I'm interested! Nope, but i did look at the libs with readelf -a and found that accesses to a global variables seems to generates a reloc per access to that global variable(why?) and that can quickly waste space. Is the system you build for ELF? If so, then it's because of the tricky ELF rules (see below). Yes, all ELF If the difference is noticeable: Have you slapped the library author with Drepper's dsohowto.pdf yet? If so, please share with us his/her reasoning to ignore it. :) Nope, not yet. Will have to slap myself and my team in that case :) Hehe. :) I have read that doc and learned a lot from it. However even Drepper seems to like -fpic in one case: glibc for ppc is compiled with -fpic. PPC can handle big libs even with -fpic. I was not thinking of `-fpic' at all. Rather of -fvisibility=hidden (or the analogous attributes for non-static functions/variables). Ah yes, that is something that should be worked upon. But we also use external libs and we don't have the manpower to hide all non global identifiers. Now the ELF issue (which is much more nicely explained in dsohowto): Every access to a global variable has to go through reloc each time. Why? If the global variable `foo' is defined in libA.so, ELF rules specify that it must be possible to intercept all use of `foo' (use from dependent libraries and programs *as well as* use from within libA) by defining another instance of `foo' in an ELF object linked in before (possibly only at runtime!). This is how some memory debugging libraries work, they overwrite `malloc', `realloc', `calloc' and `free'. yes, but within a lib you should only need one reloc for all accesses, right? If I compile 2 files into a lib, each referencing foo once, I get two relocs for foo. If I compile 1 file into a lib that reference foo twice, I get one reloc. The linker should be able to combine the first example into one reloc
