Re: rpath stripping
On Mon, 18 Apr 2022, Richard Purdie wrote: As I understand it the dynamic loader has a set of search paths it falls back to (sys_lib_dlsearch_path in libtool). An RPATH or RUNPATH entry matching a system loader path isn't usually of much use, it just takes up space. It is of use since it influences the search order. For example, if /usr/local/lib is in the system loader path, and the user installs a library in /usr/local/lib, then the user likely wants the library she has just installed to be used by apps which link with it, rather than some similar library in the default system loader path. Likewise, it is pointless to install a library which will never be used. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt
Re: rpath stripping
On Mon, 2022-04-18 at 07:39 -0400, Carlos O'Donell wrote: > On 4/17/22 10:06, Bob Friesenhahn wrote: > > The libtool I was using (originating from Ubuntu Linux) stripped the > > rpath (which was provided like '-Wl,rpath=/usr/lib') so I was unable > > to embed an rpath in the libcurl I built so that applications linked > > with that libcurl would find it. > > I agree with our position. > > The behaviour of stripping '-Wl,-rpath' is incorrect. > > With new DT_RUNPATH semantics (DT_RPATH being deprecated and binutils having > switched defaults), each shared object, including the binary, must correctly > specify the search path for the immediate needed objects. Stripping this off > will result in incorrectly built shared objects and binaries that don't > operate correctly. > > I'm curious what justification is given for this behaviour. As I understand it the dynamic loader has a set of search paths it falls back to (sys_lib_dlsearch_path in libtool). An RPATH or RUNPATH entry matching a system loader path isn't usually of much use, it just takes up space. I can imagine some cases where that might not be true such as linking with "-z nodeflib" or some fairly convoluted setups but I suspect those would have other issues too. Cheers, Richard
Re: rpath stripping
On 4/17/22 10:06, Bob Friesenhahn wrote: > The libtool I was using (originating from Ubuntu Linux) stripped the > rpath (which was provided like '-Wl,rpath=/usr/lib') so I was unable > to embed an rpath in the libcurl I built so that applications linked > with that libcurl would find it. I agree with our position. The behaviour of stripping '-Wl,-rpath' is incorrect. With new DT_RUNPATH semantics (DT_RPATH being deprecated and binutils having switched defaults), each shared object, including the binary, must correctly specify the search path for the immediate needed objects. Stripping this off will result in incorrectly built shared objects and binaries that don't operate correctly. I'm curious what justification is given for this behaviour. -- Cheers, Carlos.
Re: rpath for an inter-library dependency
Thanks Bert. This is indeed exactly the same issue I am facing. I would like the -rpath option to be added to all programs that use my .la library with the -R flag in dependency_libs, but that is not happening. As far as I understand, we agree that the documentation says that an -R flag in .la lib should result in the appropriate -rpath flags to the linker when a program linking to that library is compiled. So the patch in your email thread does the trick? The solution seems very simple. Regards, Marcin On Wed, Feb 11, 2015 at 3:39 PM, Bert Wesarg wrote: > Hi, > > On Wed, Feb 11, 2015 at 5:28 PM, Marcin Zalewski > wrote: >> Hello. >> >> I have a contrib jemalloc library in my project that is not being >> built using libtool. When I build my libtool library, I add this to >> the link line: >> >> -ljemalloc -R/rpath/to/jemalloc >> >> This works fine, and my .la file includes: >> >> dependency_libs=' -R/rpath/to/jemalloc -ljemalloc' >> >> However, when I link my programs with the .la file, I do not get rpath >> on the liker line, which causes a run-time failure when the program is >> run. Am I using the -R option correctly? I was hoping that I could >> make it a dependency in my .la file and not have to worry about it. >> The documentation for -R says: >> >> If output-file is a program, add libdir to its run-time path. If >> output-file is a library, add -Rlibdir to its dependency_libs, so >> that, whenever the library is linked into a program, libdir will be >> added to its run-time path. >> >> As far as I understood this, once my library has this dependency, the >> rpath will be added to any program that links to my library, but that >> is not happening. > > this is a known problem, though it seems that it is not considered as > one by the libtool team: > > http://lists.gnu.org/archive/html/libtool/2011-11/msg00010.html > > Bert > >> >> Any help would be appreciated, >> -m ___ https://lists.gnu.org/mailman/listinfo/libtool
Re: rpath for an inter-library dependency
Robert, On Wed, Feb 11, 2015 at 9:46 PM, Robert Boehne wrote: > So if I read these correctly, you specify the runtime path with -R but not > the link time location with -L ? where did you get the impression, that I did not specify -L in conjunction with -R? We obviously do this, because linking always succeeds, but running the application not, because the runtime path is missing. > Does too run without help if you specify > both when you build your Libtool library? It is not about building libtool libraries, it is about linking applications against libtool libraries, which depend on other libraries which need rpath information. Bert > > Robert Boehne > > On Feb 11, 2015 2:39 PM, "Bert Wesarg" wrote: >> >> Hi, >> >> On Wed, Feb 11, 2015 at 5:28 PM, Marcin Zalewski >> wrote: >> > Hello. >> > >> > I have a contrib jemalloc library in my project that is not being >> > built using libtool. When I build my libtool library, I add this to >> > the link line: >> > >> > -ljemalloc -R/rpath/to/jemalloc >> > >> > This works fine, and my .la file includes: >> > >> > dependency_libs=' -R/rpath/to/jemalloc -ljemalloc' >> > >> > However, when I link my programs with the .la file, I do not get rpath >> > on the liker line, which causes a run-time failure when the program is >> > run. Am I using the -R option correctly? I was hoping that I could >> > make it a dependency in my .la file and not have to worry about it. >> > The documentation for -R says: >> > >> > If output-file is a program, add libdir to its run-time path. If >> > output-file is a library, add -Rlibdir to its dependency_libs, so >> > that, whenever the library is linked into a program, libdir will be >> > added to its run-time path. >> > >> > As far as I understood this, once my library has this dependency, the >> > rpath will be added to any program that links to my library, but that >> > is not happening. >> >> this is a known problem, though it seems that it is not considered as >> one by the libtool team: >> >> http://lists.gnu.org/archive/html/libtool/2011-11/msg00010.html >> >> Bert >> >> > >> > Any help would be appreciated, >> > -m >> >> ___ >> https://lists.gnu.org/mailman/listinfo/libtool ___ https://lists.gnu.org/mailman/listinfo/libtool
Re: rpath for an inter-library dependency
So if I read these correctly, you specify the runtime path with -R but not the link time location with -L ? Does too run without help if you specify both when you build your Libtool library? Robert Boehne On Feb 11, 2015 2:39 PM, "Bert Wesarg" wrote: > Hi, > > On Wed, Feb 11, 2015 at 5:28 PM, Marcin Zalewski > wrote: > > Hello. > > > > I have a contrib jemalloc library in my project that is not being > > built using libtool. When I build my libtool library, I add this to > > the link line: > > > > -ljemalloc -R/rpath/to/jemalloc > > > > This works fine, and my .la file includes: > > > > dependency_libs=' -R/rpath/to/jemalloc -ljemalloc' > > > > However, when I link my programs with the .la file, I do not get rpath > > on the liker line, which causes a run-time failure when the program is > > run. Am I using the -R option correctly? I was hoping that I could > > make it a dependency in my .la file and not have to worry about it. > > The documentation for -R says: > > > > If output-file is a program, add libdir to its run-time path. If > > output-file is a library, add -Rlibdir to its dependency_libs, so > > that, whenever the library is linked into a program, libdir will be > > added to its run-time path. > > > > As far as I understood this, once my library has this dependency, the > > rpath will be added to any program that links to my library, but that > > is not happening. > > this is a known problem, though it seems that it is not considered as > one by the libtool team: > > http://lists.gnu.org/archive/html/libtool/2011-11/msg00010.html > > Bert > > > > > Any help would be appreciated, > > -m > > ___ > https://lists.gnu.org/mailman/listinfo/libtool > ___ https://lists.gnu.org/mailman/listinfo/libtool
Re: rpath for an inter-library dependency
Hi, On Wed, Feb 11, 2015 at 5:28 PM, Marcin Zalewski wrote: > Hello. > > I have a contrib jemalloc library in my project that is not being > built using libtool. When I build my libtool library, I add this to > the link line: > > -ljemalloc -R/rpath/to/jemalloc > > This works fine, and my .la file includes: > > dependency_libs=' -R/rpath/to/jemalloc -ljemalloc' > > However, when I link my programs with the .la file, I do not get rpath > on the liker line, which causes a run-time failure when the program is > run. Am I using the -R option correctly? I was hoping that I could > make it a dependency in my .la file and not have to worry about it. > The documentation for -R says: > > If output-file is a program, add libdir to its run-time path. If > output-file is a library, add -Rlibdir to its dependency_libs, so > that, whenever the library is linked into a program, libdir will be > added to its run-time path. > > As far as I understood this, once my library has this dependency, the > rpath will be added to any program that links to my library, but that > is not happening. this is a known problem, though it seems that it is not considered as one by the libtool team: http://lists.gnu.org/archive/html/libtool/2011-11/msg00010.html Bert > > Any help would be appreciated, > -m ___ https://lists.gnu.org/mailman/listinfo/libtool
Re: rpath configuration
On May 30, 2013 8:03 PM, "Gary V. Vaughan" wrote: > > Hi Bob, > > On 31 May 2013, at 09:57, "Gary V. Vaughan" wrote: > > On 31 May 2013, at 08:28, Bob Rossi wrote: > >> On Fri, May 24, 2013 at 07:15:50PM -0400, Bob Rossi wrote: > >>> I'm building a program that links against boost with libtool. > >>> > >>> The boost library is installed on the system and is a shared library. > >>> > >>> When i run my program ./test_suite I get, > >>> $ ./test_suite > >>> .../build/.libs/lt-test_suite: error while loading shared libraries: libboost_filesystem.so.1.53.0: cannot open shared object file: No such file or directory > > Didn't notice this on first blush, sorry. It seems you are getting a libtool > link invocation out of Automake after all, so you can probably ignore most of > my earlier reply. > > This error seems to indicate that the ./test_suite wrapper script is not > setting LD_LIBRARY_PATH correctly. Take a look inside that script to see what > is going on, and get some clues of what went wrong with the link. Or do "./libtool --mode=run your command line" to have libtool set the appropriate paths for you. Dan ___ https://lists.gnu.org/mailman/listinfo/libtool
Re: rpath configuration
Hi Bob, On 31 May 2013, at 09:57, "Gary V. Vaughan" wrote: > On 31 May 2013, at 08:28, Bob Rossi wrote: >> On Fri, May 24, 2013 at 07:15:50PM -0400, Bob Rossi wrote: >>> I'm building a program that links against boost with libtool. >>> >>> The boost library is installed on the system and is a shared library. >>> >>> When i run my program ./test_suite I get, >>> $ ./test_suite >>> .../build/.libs/lt-test_suite: error while loading shared libraries: >>> libboost_filesystem.so.1.53.0: cannot open shared object file: No such file >>> or directory Didn't notice this on first blush, sorry. It seems you are getting a libtool link invocation out of Automake after all, so you can probably ignore most of my earlier reply. This error seems to indicate that the ./test_suite wrapper script is not setting LD_LIBRARY_PATH correctly. Take a look inside that script to see what is going on, and get some clues of what went wrong with the link. Cheers, -- Gary V. Vaughan (gary AT gnu DOT org) ___ https://lists.gnu.org/mailman/listinfo/libtool
Re: rpath configuration
Hi Bob, On 31 May 2013, at 08:28, Bob Rossi wrote: > Ping. > > Is this the active libtool mailing list? Yes it is. If you don't get a reply it means that nobody who read your request is confident about the right answer. In my case, I only know just enough about C++ to avoid it at all costs, which is why I didn't respond initially :) > On Fri, May 24, 2013 at 07:15:50PM -0400, Bob Rossi wrote: >> I'm building a program that links against boost with libtool. >> >> The boost library is installed on the system and is a shared library. >> >> When i run my program ./test_suite I get, >> $ ./test_suite >> .../build/.libs/lt-test_suite: error while loading shared libraries: >> libboost_filesystem.so.1.53.0: cannot open shared object file: No such file >> or directory >> >> My Makefile looks like, >> >> noinst_PROGRAMS += test_suite To avoid building the test_suite unless invoked with `make check` you can use: check_PROGRAMS += test_suite >> test_suite_SOURCES = \ >>src/progs/test_suite/fixture.cpp \ >>src/progs/test_suite/main.cpp >> >> test_suite_CPPFLAGS = \ >>@BOOST_CPPFLAGS@ >> >> test_suite_LDFLAGS = \ >>@BOOST_LDFLAGS@ >> >> test_suite_LDADD = \ >>@BOOST_LIBS@ >> >> Where the boost variables are, >> BOOST_CPPFLAGS = -IBOOSTDIR/boost_1_53_0_prefix/include Not literally -IBOOSTDIR I trust. You probably need something more like: -I $(BOOSTDIR)/... >> BOOST_LDFLAGS = -LBOOSTDIR/boost_1_53_0_prefix/lib Likewise. >> BOOST_LIBS = -lboost_filesystem -lboost_system >> >> I have a few questions. >> >> For linking against system libraries, is using LDFLAGS and LDADD >> appropriate the way I have done it? I don't see any reference to libtool or a libtool archive here, so how does Automake know it should be linking with libtool in this case? Unfortunately, some distributions remove the .la files from system directories that libtool uses to figure out the correct linker invocation. If your system is missing files such as: $(BOOSTDIR)/boost_1_53_0_prefix/lib/boost_system.la ...then you have to force Automake to use libtool. Check the Automake manual for details of how to set test_suite_LINK appropriately. Also, you need to add the CXX tag to LT_INIT to incorporate C++ settings into your generated project libtool script, if you didn't do that already. >> Is it my responsibility to add the -rpath libtool option to include >> BOOSTDIR/boost_1_53_0_prefix/lib? Libtool's -rpath option is for specifying the target library's install destination, not for adding the location of deplibs. Automake will set -rpath for you, so there's almost never any need to specify it manually. >> Should I be setting LD_LIBRARY_PATH when running from the build >> directory? No, libtool will take care of that (LD_LIBRARY_PATH is just one spelling of that variable for linux and a few other Unices) automatically. >> I notice that when I link against libtool created libraries in the >> same Makefile I don't see this issue at all. Is that because Automake can tell you want to link using libtool, but in the case of the Makefile.am you paste above, Automake thinks you want to link with g++? Please show the output from running make to demonstrate what you are actually seeing. Cheers, -- Gary V. Vaughan (gary AT gnu DOT org) ___ https://lists.gnu.org/mailman/listinfo/libtool
Re: rpath configuration
On Fri, May 24, 2013 at 07:15:50PM -0400, Bob Rossi wrote: > I'm building a program that links against boost with libtool. > > The boost library is installed on the system and is a shared library. > > When i run my program ./test_suite I get, > $ ./test_suite > .../build/.libs/lt-test_suite: error while loading shared libraries: > libboost_filesystem.so.1.53.0: cannot open shared object file: No such file > or directory > > My Makefile looks like, > > noinst_PROGRAMS += test_suite > > test_suite_SOURCES = \ > src/progs/test_suite/fixture.cpp \ > src/progs/test_suite/main.cpp > > test_suite_CPPFLAGS = \ > @BOOST_CPPFLAGS@ > > test_suite_LDFLAGS = \ > @BOOST_LDFLAGS@ > > test_suite_LDADD = \ > @BOOST_LIBS@ > > Where the boost variables are, > BOOST_CPPFLAGS = -IBOOSTDIR/boost_1_53_0_prefix/include > BOOST_LDFLAGS = -LBOOSTDIR/boost_1_53_0_prefix/lib > BOOST_LIBS = -lboost_filesystem -lboost_system > > I have a few questions. > > For linking against system libraries, is using LDFLAGS and LDADD > appropriate the way I have done it? > > Is it my responsibility to add the -rpath libtool option to include > BOOSTDIR/boost_1_53_0_prefix/lib? > > Should I be setting LD_LIBRARY_PATH when running from the build > directory? > > I notice that when I link against libtool created libraries in the > same Makefile I don't see this issue at all. Ping. Is this the active libtool mailing list? Bob ___ https://lists.gnu.org/mailman/listinfo/libtool
Re: rpath
* Joakim Tjernlund wrote on Sun, Dec 13, 2009 at 12:26:18PM CET: > 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? Specify with configure --prefix the *final* location of the installed code: where it will be when the end-user runs it. Divert installation elsewhere with `make install DESTDIR=...'. If that doesn't fit your directory layout, that can be a problem. Libtool unfortunately doesn't yet cope with arbitrary install-time diversions a la `make install prefix=...'. Cheers, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: rpath
Ralf Wildenhues 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
* 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 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". Cheers, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: rpath
Ralf Corsepius 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
Re: rpath
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. Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: rpath
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. Thanks, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: rpath
Ralf Wildenhues wrote: * Joakim Tjernlund wrote on Thu, Dec 10, 2009 at 08:04:27AM CET: Ralf Wildenhues wrote on 10/12/2009 06:16:40: * 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? Well you can AC_ARG_VAR([DESTDIR], [perform staged installation using DESTDIR]) This require makefiles generated by configure script to contain line like this one: destd...@destdir@ otherwise it is useless I won't like to discuss more what happen if user forget DESTDIR as it is not required "at every make". DESTDIR is usefull only if user would like to create distribution archive and for every package DESTDIR is good to point to clean directory tree. Other point is that on unix(linux) user work under unprivileged account and only for install is required a privileged account(root). but it will require your users to either specify it at configure time already, or, if they want to specify it at `make install' time only, use GNU make. Cheers, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: rpath
* Joakim Tjernlund wrote on Thu, Dec 10, 2009 at 08:04:27AM CET: > Ralf Wildenhues wrote on 10/12/2009 06:16:40: > > * 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? Well you can AC_ARG_VAR([DESTDIR], [perform staged installation using DESTDIR]) but it will require your users to either specify it at configure time already, or, if they want to specify it at `make install' time only, use GNU make. Cheers, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: rpath
Ralf Wildenhues wrote on 10/12/2009 06:16:40: > From: Ralf Wildenhues > To: Joakim Tjernlund > 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
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. Cheers, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: rpath
Ralf Wildenhues wrote on 08/12/2009 20:13:13: > From: Ralf Wildenhues > To: Joakim Tjernlund > 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
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 Cheers, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: rpath
On Tuesday 08 December 2009 03:44:57 Joakim Tjernlund wrote: > 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? what did you set your libdir/prefix/etc... to ? -mike signature.asc Description: This is a digitally signed message part. ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: rpath in later versions of libtool
Hello John, * John R. Cary wrote on Fri, Aug 07, 2009 at 11:49:39PM CEST: > I am trying to use libtool to make a static executable: > > /bin/sh ../libtool --tag=CXX --mode=link g++ -g -O2 -pipe -Wall > -Wno-unused-static -o uecxxst ../uebase/uedge.o libuecxxst.la > ../uestat/.libs/libuestat.a ../uebase/libuebase.a > ../vshdf5/.libs/libvshdf5.a > -L/usr/local/contrib/babel-1.4.0-r6662p1-static/lib -lsidl > -lsidlstub_cxx -lsidlstub_f90 > -L/usr/local/contrib/petsc-3.0.0-p7-ser/lib -rpath > /usr/local/contrib/petsc-3.0.0-p7-ser/lib -lpetscts -lpetscsnes > -lpetscksp -lpetscdm -lpetscmat -lpetscvec -lpetsc -lsuperlu_3.1 > -llapack -lblas -lmpiuni > /usr/local/contrib/netlib_lite-1.0.4-ser/lib/libnetlib_lite.a > /usr/local/contrib/hdf5-1.8.2-ser/lib/libhdf5_fortran.a > /usr/local/contrib/hdf5-1.8.2-ser/lib/libhdf5.a > /usr/local/internal/txbase-r243-ser/lib/gcc4/libtxbase.a -llapack > /usr/lib64/libblas.so -lgfortranbegin -lgfortran -lm -lz -rpath > /usr/lib/gcc/x86_64-redhat-linux/4.4.0 -ldl > > but it ends up not finding some libraries: > > iter.cary$ ldd uecxxst >linux-vdso.so.1 => (0x7fffad9ff000) >libblas.so.3 => /usr/lib64/libblas.so.3 (0x7fb6a5685000) >libpetscts.so => not found >libpetscsnes.so => not found >libpetscksp.so => not found >libpetscdm.so => not found >libpetscmat.so => not found >libpetscvec.so => not found >libpetsc.so => not found >liblapack.so.3 => /usr/lib64/atlas/liblapack.so.3 > On the libtool line I had both '-static' and '-rpath > /usr/local/contrib/petsc-3.0.0-p7-ser/lib' > with the latter being where the libs are found: > iter.cary$ \ls /usr/local/contrib/petsc-3.0.0-p7-ser/lib > libmpiuni.a libpetscdm.so libpetscsnes.a libpetscvec.a [...] > One can see that the -rpath on the link line is not generating anything > like '-Wl,-rpath,...' on the g++ link line. Try using -R $path instead of -rpath $path. If that fixes it, it seems we have a regression to take care of. Cheers, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: rpath in later versions of libtool (fwd)
I forgot to cc the listJohn Cary -- Tech-X Corp., 5621 Arapahoe Ave, Suite A, Boulder CO 80303 c...@txcorp.com, p 303-448-0727, f 303-448-7756 -- Forwarded message -- Date: Sat, 08 Aug 2009 15:14:54 -0600 From: John R. Cary To: Bob Friesenhahn Subject: Re: rpath in later versions of libtool Bob Friesenhahn wrote: On Fri, 7 Aug 2009, John R. Cary wrote: > > I am trying to use libtool to make a static executable: > > /bin/sh ../libtool --tag=CXX --mode=link g++ -g -O2 -pipe -Wall > -Wno-unused-static -o uecxxst ../uebase/uedge.o libuecxxst.la > ../uestat/.libs/libuestat.a ../uebase/libuebase.a > ../vshdf5/.libs/libvshdf5.a > -L/usr/local/contrib/babel-1.4.0-r6662p1-static/lib -lsidl -lsidlstub_cxx > -lsidlstub_f90 -L/usr/local/contrib/petsc-3.0.0-p7-ser/lib -rpath > /usr/local/contrib/petsc-3.0.0-p7-ser/lib -lpetscts -lpetscsnes -lpetscksp > -lpetscdm -lpetscmat -lpetscvec -lpetsc -lsuperlu_3.1 -llapack -lblas > -lmpiuni/usr/local/contrib/netlib_lite-1.0.4-ser/lib/libnetlib_lite.a > /usr/local/contrib/hdf5-1.8.2-ser/lib/libhdf5_fortran.a > /usr/local/contrib/hdf5-1.8.2-ser/lib/libhdf5.a > /usr/local/internal/txbase-r243-ser/lib/gcc4/libtxbase.a -llapack > /usr/lib64/libblas.so -lgfortranbegin -lgfortran -lm -lz -rpath > /usr/lib/gcc/x86_64-redhat-linux/4.4.0 -ldl > > but it ends up not finding some libraries: >libatlas.so.3 => /usr/lib64/atlas/libatlas.so.3 (0x7fb6a3f01000) > > One can see that the -rpath on the link line is not generating anything > like '-Wl,-rpath,...' on the g++ link line. Actually, we can't see that since you omitted the useful libtool output where it prints what it actually invoked. Argh. Here it is: libtool: link: g++ -g -O2 -pipe -Wall -Wno-unused -o uecxxst ../uebase/uedge.o /usr/lib64/libblas.so ./.libs/libuecxxst.a ../uestat/.libs/libuestat.a ../uebase/libuebase.a ../vshdf5/.libs/libvshdf5.a -L/usr/local/contrib/babel-1.4.0-r6662p1-static/lib /contrib/babel-1.4.0-r6662p1-static/lib/libsidlstub_cxx.a /contrib/babel-1.4.0-r6662p1-static/lib/libsidlstub_f90.a -L/usr/lib/gcc/x86_64-redhat-linux/4.4.0 /contrib/babel-1.4.0-r6662p1-static/lib/libsidl.a /contrib/babel-1.4.0-r6662p1-static/lib/libchasmlite.a -L/usr/local/contrib/petsc-3.0.0-p7-ser/lib -lpetscts -lpetscsnes -lpetscksp -lpetscdm -lpetscmat -lpetscvec -lpetsc -lsuperlu_3.1 -lblas -lmpiuni /usr/local/contrib/netlib_lite-1.0.4-ser/lib/libnetlib_lite.a /usr/local/contrib/hdf5-1.8.2-ser/lib/libhdf5_fortran.a /usr/local/contrib/hdf5-1.8.2-ser/lib/libhdf5.a /usr/local/internal/txbase-r243-ser/lib/gcc4/libtxbase.a -llapack -lgfortranbegin -lgfortran -lm -lz -ldl -pthread > what am I doing wrong? My first guess is that there is a problem with supplying -rpath multiple times on the command line. If this is the problem, perhaps libtool's output about what it is doing would include only -Wl,-rpath,/usr/lib/gcc/x86_64-redhat-linux/4.4.0 since that is the last -rpath option supplied. The other possibility is that the problem libraries have not been registered with the system using 'ldconfig' and perhaps Linux needs that. Thanks for your suggestions. I see no -Wl,-rpath anywhere above. As for ldconfig, it that registration were necessary, I guess that would obviate the need for rpath? ThxJohn Cary -- Tech-X Corp., 5621 Arapahoe Ave, Suite A, Boulder CO 80303 c...@txcorp.com, p 303-448-0727, f 303-448-7756, NEW CELL 303-881-8572 ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: rpath in later versions of libtool
On Fri, 7 Aug 2009, John R. Cary wrote: I am trying to use libtool to make a static executable: /bin/sh ../libtool --tag=CXX --mode=link g++ -g -O2 -pipe -Wall -Wno-unused-static -o uecxxst ../uebase/uedge.o libuecxxst.la ../uestat/.libs/libuestat.a ../uebase/libuebase.a ../vshdf5/.libs/libvshdf5.a -L/usr/local/contrib/babel-1.4.0-r6662p1-static/lib -lsidl -lsidlstub_cxx -lsidlstub_f90 -L/usr/local/contrib/petsc-3.0.0-p7-ser/lib -rpath /usr/local/contrib/petsc-3.0.0-p7-ser/lib -lpetscts -lpetscsnes -lpetscksp -lpetscdm -lpetscmat -lpetscvec -lpetsc -lsuperlu_3.1 -llapack -lblas -lmpiuni/usr/local/contrib/netlib_lite-1.0.4-ser/lib/libnetlib_lite.a /usr/local/contrib/hdf5-1.8.2-ser/lib/libhdf5_fortran.a /usr/local/contrib/hdf5-1.8.2-ser/lib/libhdf5.a /usr/local/internal/txbase-r243-ser/lib/gcc4/libtxbase.a -llapack /usr/lib64/libblas.so -lgfortranbegin -lgfortran -lm -lz -rpath /usr/lib/gcc/x86_64-redhat-linux/4.4.0 -ldl but it ends up not finding some libraries: libatlas.so.3 => /usr/lib64/atlas/libatlas.so.3 (0x7fb6a3f01000) One can see that the -rpath on the link line is not generating anything like '-Wl,-rpath,...' on the g++ link line. Actually, we can't see that since you omitted the useful libtool output where it prints what it actually invoked. what am I doing wrong? My first guess is that there is a problem with supplying -rpath multiple times on the command line. If this is the problem, perhaps libtool's output about what it is doing would include only -Wl,-rpath,/usr/lib/gcc/x86_64-redhat-linux/4.4.0 since that is the last -rpath option supplied. The other possibility is that the problem libraries have not been registered with the system using 'ldconfig' and perhaps Linux needs that. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: -rpath problem , relative paths not allowed
Hi Mike, First off: I've moderated your post through yesterday, but it also seems to be a victim of the current list server issues; maybe all those missing messages eventually appear. Quoting generously thus: * Mike Mattie wrote on Sat, Mar 25, 2006 at 05:59:22PM CET: > as I understand it the -rpath arguement to libtool is actually the > installation path of the shared object. I need that to be a relative > path. That is not supported at the moment, unfortunately. It's a TODO item, though. Not trivial though to do right. > The reason it needs to be relative is because the shared object is going > into a .jar file, so an absolute path is meaningless for the loader. > > my install target serves no other purpose than to assemble the contents > of the .jar file before running the jar command. > > Maybe I can pass it an absolute path formed by the build dir, plus the > relative directory I actually want it to install to. But I am afraid > that libtool has overloaded -rpath , and makes assumptions about what > that is, beyond a install path to put the file. Why else would it care > if it's relative or absolute ? Well, I think when this semantics were invented, the thoughts were about like this: there are shared library systems that simply won't allow you anything except an absolute path, so being portable, this is what you have to assume. Certainly that was before java was supported by Libtool. > My question is this: can I pass an -rpath as a installation path without > that path showing up in my shared objects post compilation/link ? Libtool does not put such a path into its output if it belongs to the set of paths that are searched by the runtime loader by default; see the sys_lib_dlsearch_path_spec variable. But no, there is no documented way at the moment to achieve what you need; you could override that variable manually in the libtool script, as a hack. Cheers, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: RPATH on x86_64?
[ note: list lag is still days: see http://savannah.gnu.org/forum/forum.php?forum_id=4322 ] * Pierre Ossman wrote on Wed, Mar 01, 2006 at 10:00:43AM CET: > Ralf Wildenhues wrote: > > > >In theory: no run paths for paths that the runtime linker searches by > >default. Otherwise, rpaths for all libraries we link directly against. > >(Omitting the minor detail that we care about the difference of > >uninstalled vs. installed locations, for simplicity.) > > If I read the above threads correctly there are some problems > determining the runtime paths automatically (mainly because gcc doesn't > give the complete picture). Yes, more or less. We also have a similar issue on Solaris/64 ATM, but that should be fixable by looking at $host and $LD (as we compute it). > In this case, user assistance is acceptable, > so would adding a -R to the libtool invocation make it stop adding rpaths? No. Au contraire: -R is the flag to add more run paths, not to remove them. > Is there perhaps also some environment variable that can be used to pass > this information? That would allow "make RPATHENV=/usr/lib64" and I > wouldn't have to mess with the build system. Not at the moment. You could change the setting of sys_lib_dlsearch_path_spec in the generated libtool script (once for each tag). An patch implementing a functionality like the one you desire would be useful. I'm just not sure about exact semantics and syntax: - a `libtool --mode=link' option, or - an environment variable, or - a configure option Note there's also been the suggestion to allow a specific environment variable to contain all kinds of libtool options; or one for each mode. Next question: should it be possible to - add paths to this list, or - remove paths, or - just set the path list to something new? Should the paths be normalized or not? Which setting should override which? If we can agree on something sane here, I'm all for moving forward an implementing it. In practice, some distributions have added patches to their installed libtool.m4 to adjust sys_lib_dlsearch_path_spec and sys_lib_search_path_spec to their way of doing it. Good for their packages, but makes for interesting failures when you then take a tarball created there to another distribution. Cheers, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: RPATH on x86_64?
Ralf Wildenhues wrote: * Pierre Ossman wrote on Wed, Mar 01, 2006 at 10:00:43AM CET: Is there perhaps also some environment variable that can be used to pass this information? That would allow "make RPATHENV=/usr/lib64" and I wouldn't have to mess with the build system. Not at the moment. You could change the setting of sys_lib_dlsearch_path_spec in the generated libtool script (once for each tag). An patch implementing a functionality like the one you desire would be useful. I'm just not sure about exact semantics and syntax: - a `libtool --mode=link' option, or - an environment variable, or - a configure option configure option is probably the safest. That way we avoid exotic breakage if some other part relies on the stability of the library path list. OTOH, that would not allow having different settings for different parts of the build. In that case an argument upon invocation would be better. Environment variables should be a complement, not the primary way of controlling it. Note there's also been the suggestion to allow a specific environment variable to contain all kinds of libtool options; or one for each mode. It would fit in with the CFLAGS/LDFLAGS/etc. that are used for other build tools. Next question: should it be possible to - add paths to this list, or - remove paths, or - just set the path list to something new? Add would be the most desirable version. Do we have any use cases for the other two? Should the paths be normalized or not? I'm not familiar with the problems of normalised vs not normalised, but my gut instinct is to use whatever the user provides. If they for some reason need relative paths then let them add that. Which setting should override which? Strictly in the order specified would be the most familiar way of doing things. Rgds -- Pierre OssmanTelephone: +46-13-21 46 00 Cendio ABWeb: http://www.cendio.com ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: RPATH on x86_64?
Ralf Wildenhues wrote: In theory: no run paths for paths that the runtime linker searches by default. Otherwise, rpaths for all libraries we link directly against. (Omitting the minor detail that we care about the difference of uninstalled vs. installed locations, for simplicity.) If I read the above threads correctly there are some problems determining the runtime paths automatically (mainly because gcc doesn't give the complete picture). In this case, user assistance is acceptable, so would adding a -R to the libtool invocation make it stop adding rpaths? Is there perhaps also some environment variable that can be used to pass this information? That would allow "make RPATHENV=/usr/lib64" and I wouldn't have to mess with the build system. Thanks -- Pierre OssmanTelephone: +46-13-21 46 00 Cendio ABWeb: http://www.cendio.com ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: RPATH on x86_64?
Hi Pierre, * Pierre Ossman wrote on Mon, Feb 27, 2006 at 09:15:34AM CET: > > I've noticed that when I do a build on x86_64, RPATH gets set in the > binaries. This does not happen when I build on x86, so it seems it's > libtool (perhaps as a result of autoconf, but still) that decides to do > this. http://lists.gnu.org/archive/cgi-bin/namazu.cgi?query=multilib&submit=Search%21&idxname=libtool&max=20&result=normal&sort=score Several of these are interesting. > I've looked through the code but it's a bit hard to read. Why do you think the code is hard to read? ;-) > So I was > hoping someone could explain in plain English how it's supposed to work. :) In theory: no run paths for paths that the runtime linker searches by default. Otherwise, rpaths for all libraries we link directly against. (Omitting the minor detail that we care about the difference of uninstalled vs. installed locations, for simplicity.) Now, in theory, theory and reality are the same. And all GNU/Linux distributions have the same multilib layout. :-/ Cheers, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: rpath command?
In message <[EMAIL PROTECTED]>, Alexandre Oliva writes: >[linking a library from other libraries with no object files] > >The point is that this just can't be done portably. Since libtool's major purpose is to allow libraries to be built using a portable interface, perhaps it should take care of this for the developer? So on platforms where this doesn't work, perhaps libtool should add a dummy file implicitly, rather than the developer having to implement the bodge themselves? >(ii) automake wouldn't know which compiler/linker to use for the >library you're creating. Specifying one or more source files is >supposed to give automake a clue on which languages are being used in >the sub-libraries. This would be an obstacle to libtool creating the bodge file, but the .la file could be extended to contain information about languages used in a libtool library. Cheers, Olly ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: rpath command?
On Nov 27, 2000, Steve Robbins <[EMAIL PROTECTED]> wrote:
> What I would like to do is:
> lib_LTLIBRARIES = libfoo.la
> libfoo_la_LIBADD = \
> $(top_builddir)/a/adummy.la \
> $(top_builddir)/b/bdummy.la \
> $(top_builddir)/c/cdummy.la \
> $(top_builddir)/d/ddummy.la
The point is that this just can't be done portably. You need at least
one object file, for two reasons:
(i) libtool may fail if you link only libtool archives into another
libtool archive
(ii) automake wouldn't know which compiler/linker to use for the
library you're creating. Specifying one or more source files is
supposed to give automake a clue on which languages are being used in
the sub-libraries.
> Is it impossible to support building libraries out of ONLY other
> libraries?
Yes. It isn't portable. Some linkers just fail.
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist*Please* write to mailing lists, not to me
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
Re: rpath command?
On 27 Nov 2000, Alexandre Oliva wrote: > On Nov 25, 2000, Tom Tromey <[EMAIL PROTECTED]> wrote: > > >>> Do I have to use some macro in configure.in to fill $(LINK) with GNU ld? > Alexandre> automake should define it to `$(LIBTOOL) $(CC/CXX)...'. > Alexandre> Maybe it only does this when there is at least one source > Alexandre> file to compile in the current directory? > > > Yeah, that's how it works. I realize this is less than good. Can you > > suggest how it ought to work? > > I think the current behavior is fine, since it is indeed invalid to > create a library or libtool archive out of no source files. However, > we might output a warning (or even an error) if we find a request to > create a library out of no source files. I'm not so sure about this. Unless the CVS versions of the tools have changed things, the current behaviour makes it impossible to create a library consisting only of sources in subdirectories. What I would like to do is: lib_LTLIBRARIES = libfoo.la libfoo_la_LIBADD = \ $(top_builddir)/a/adummy.la \ $(top_builddir)/b/bdummy.la \ $(top_builddir)/c/cdummy.la \ $(top_builddir)/d/ddummy.la but this fails, so I generally add: libfoo_la_SOURCES = dummy.c dummy.c: touch dummy.c To me, the last bit seems like a workaround for a bug. Is it impossible to support building libraries out of ONLY other libraries? -S ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: rpath command?
> > Yeah, that's how it works. I realize this is less than good. Can you > > suggest how it ought to work? > > I think the current behavior is fine, since it is indeed invalid to > create a library or libtool archive out of no source files. However, > we might output a warning (or even an error) if we find a request to > create a library out of no source files. It should be made clear, if it is a bug or a feature. And a sentence or two in the .info documentation about this situation would be welcome too - just to prevent that one wastes time trying to achieve something that is not supposed to work that way. Regards, Marc ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: rpath command?
On Nov 25, 2000, Tom Tromey <[EMAIL PROTECTED]> wrote:
>>> Do I have to use some macro in configure.in to fill $(LINK) with GNU ld?
Alexandre> automake should define it to `$(LIBTOOL) $(CC/CXX)...'.
Alexandre> Maybe it only does this when there is at least one source
Alexandre> file to compile in the current directory?
> Yeah, that's how it works. I realize this is less than good. Can you
> suggest how it ought to work?
I think the current behavior is fine, since it is indeed invalid to
create a library or libtool archive out of no source files. However,
we might output a warning (or even an error) if we find a request to
create a library out of no source files.
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist*Please* write to mailing lists, not to me
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
Re: rpath command?
>> Do I have to use some macro in configure.in to fill $(LINK) with GNU ld? Alexandre> automake should define it to `$(LIBTOOL) $(CC/CXX)...'. Alexandre> Maybe it only does this when there is at least one source Alexandre> file to compile in the current directory? Yeah, that's how it works. I realize this is less than good. Can you suggest how it ought to work? Tom ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: rpath command?
On Nov 22, 2000, Marc van Woerkom <[EMAIL PROTECTED]> wrote:
>> automake should define it to `$(LIBTOOL) $(CC/CXX)...'. Maybe it only
>> does this when there is at least one source file to compile in the
>> current directory?
> Bingo!
> Makefile.am:
> libSciFacBase_la_SOURCES = \
>buildme.c
And you'd be surprised at the number of problems you'd encounter if
you didn't link at least one object file into a library.
> buildme.c:
> /* void do_really_nothing_useful() { } */
This is not a valid C program. A C program must contain at least one
valid declaration. Try something like `static int i;'
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist*Please* write to mailing lists, not to me
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
Re: rpath command?
> automake should define it to `$(LIBTOOL) $(CC/CXX)...'. Maybe it only
> does this when there is at least one source file to compile in the
> current directory?
Bingo!
After introducing this additions
Makefile.am:
libSciFacBase_la_SOURCES = \
buildme.c
buildme.c:
/*
void do_really_nothing_useful()
{
}
*/
it works.
Bizarre, I can't believe it. :-)
This project now features a source tree with customizable modules,
handles module dependencies, builds in separate build tree, installs
in seperate build tree..
[mvw@pcserver scifac.build]$ ../scifac/configure
--prefix=/home/mvw/work/scifac.install --without-Dataserver --without-Dataserver2
--without-Dataserver3
.. and stumbles over an empty _SOURCES list. ROTFL.
Thanks for your remark, Alexandre!
Marc
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
Re: rpath command?
> They look ok, which means you've probably found a bug in automake.
> What does Makefile.in look like (grep rpath, please :-)
[mvw@pcserver scifac]$ grep -r rpath *
Base/src/Makefile.in: $(LINK) -rpath $(libdir) $(libSciFacBase_la_LDFLAGS)
$(libSciFacBase_la_OBJECTS) $(libSciFacBase_la_LIBADD) $(LIBS)
config/ltconfig:hardcode_libdir_flag_spec='${wl}--rpath ${wl}$libdir'
(..)
config/ltmain.sh:compile_rpath=
(..)
[mvw@pcserver scifac]$
Strange. Perhaps the bootstrap is not powerful enough?
#! /bin/sh
aclocal --verbose && \
autoheader && \
automake --verbose --add-missing && \
autoconf
I tried to stick to the example in the goat book.
The difference is probably that I have no code in the
Base/src directory, where libSciFacBase should be
assembled.
What is supposed to be in $(LINK)?
Regards,
Marc
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
Re: rpath command?
On Nov 22, 2000, Marc van Woerkom <[EMAIL PROTECTED]> wrote:
> Do I have to use some macro in configure.in to fill $(LINK) with GNU ld?
automake should define it to `$(LIBTOOL) $(CC/CXX)...'. Maybe it only
does this when there is at least one source file to compile in the
current directory?
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist*Please* write to mailing lists, not to me
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
Re: rpath command?
On Nov 22, 2000, Marc van Woerkom <[EMAIL PROTECTED]> wrote:
>> > Is my libtool faulty?
>>
>> Nope, it's your Makefile. Look for lines containing rpath and fix
>> them (post'em here if you don't know how to fix them). There's no
>> such thing as an `rpath' command.
> Ok, here are the Makefile.am files:
They look ok, which means you've probably found a bug in automake.
What does Makefile.in look like (grep rpath, please :-)
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist*Please* write to mailing lists, not to me
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
Re: rpath command?
> Nope, it's your Makefile. Look for lines containing rpath and fix > them (post'em here if you don't know how to fix them). There's no > such thing as an `rpath' command. The line in the generated Makefile look like this: libSciFacBase.la: $(libSciFacBase_la_OBJECTS) $(libSciFacBase_la_DEPENDENCIES) $(LINK) -rpath $(libdir) $(libSciFacBase_la_LDFLAGS) $(libSciFacBase_la_OBJECTS) $(libSciFacBase_la_LIBADD) $(LIBS) Do I have to use some macro in configure.in to fill $(LINK) with GNU ld? Regards, Marc ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: rpath command?
> > Is my libtool faulty? > > Nope, it's your Makefile. Look for lines containing rpath and fix > them (post'em here if you don't know how to fix them). There's no > such thing as an `rpath' command. Ok, here are the Makefile.am files: --- $(top_srcdir)/Base/src/Makefile.am: # we build "convenience" libs first, then bundle these into a "real" Base lib SUBDIRS = \ util \ property \ values \ . lib_LTLIBRARIES = libSciFacBase.la libSciFacBase_la_SOURCES = libSciFacBase_la_LDFLAGS = -no-undefined -version-info 0:0:0 libSciFacBase_la_LIBADD = \ util/libSciFacBaseUtil.la \ property/libSciFacBaseProperty.la \ values/libSciFacBaseValues.la --- $(top_srcdir)/Base/src/util/Makefile.am: # note use of 'top_srcdir' set by autoconf INCLUDES = -I$(top_srcdir)/Base/inc # This will create a so called "convenience" library # # Think of it as an intermediate collection of objects that will not serve # as a library (something that gets called actually). # Later this and other convenience libs will be bundeled into a real library. noinst_LTLIBRARIES = libSciFacBaseUtil.la # headers and sources # # - headers are listed to allow complete distributions # # - those nameT.h files are actually containing template code #they are treated as headers thus automake requires them to have #.h suffix (reason: automake <= version 1.4 can only treat headers #well across directories) libSciFacBaseUtil_la_SOURCES = \ SFRefCounted.h \ SFRefCountedT.h \ SFRefCounted.cpp \ SFException.h \ SFExceptionT.h \ SFException.cpp \ SFObserver.h \ SFObserver.cpp \ SFTrace.h \ SFTrace.cpp \ SFTraceBuf.h \ SFTraceBuf.cpp --- $(top_srcdir)/Base/src/property/Makefile.am: (similiar as above) --- $(top_srcdir)/Base/src/value/Makefile.am: (similiar as above) --- Thanks for that offer, Marc ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: rpath command?
On Nov 22, 2000, Marc van Woerkom <[EMAIL PROTECTED]> wrote:
> Is my libtool faulty?
Nope, it's your Makefile. Look for lines containing rpath and fix
them (post'em here if you don't know how to fix them). There's no
such thing as an `rpath' command.
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist*Please* write to mailing lists, not to me
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
