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. 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. Cheers, Ralf ___ 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: 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
lt_dlerror 'file not found' bug
Hello, this is ltdl-related, especially related to the case when you try to open an invalid module without knowing that it actually is invalid. The story is that if you try to lt_dlopen a module that can't be dlopened (for example when it has unsatisfied dependencies), the lt_dlopen function will return null module handle. If you want to know where is the problem, you usually call the lt_dlerror() function immediatelly afterwards and examine the error string. The problem is that you always get the 'file not found' message. But it is not the case: If you manage to fix the error in your module, you can experience that it becomes magically dlopenable, although all files remain on the same place as before. This is caused by lt_dlopen's behavior: It may not know what file to actually open. Even if you pass the module's .la file, which should be by intuition the best solution, it attempts to dlopen all sorts of files, some of them may even not be present. Therefore if one attempt fails, lt_dlopen tries the next one. And this happens even if the reason of the failiure was not the inability to locate the file. If everything fails, an error is set. Obviously it is the error from the last attempt, that usually is that 'file not found' case. The error that matters is therefore overwritten by every subsequent error. I have briefly tested the git version, the bug is still there. I would like to contribute to fix this bug. Could you please provide me with advice here and there? What I have thought of is stopping any attempt to open any new module filename if the previous attempt has failed for another reason that because the file wasn't there. Do you think this is a good assumption? Regards, Matej ___ http://lists.gnu.org/mailman/listinfo/libtool
ltdl - how to export from modules
Hello, if you want to lt_dlsym functions from your modules, how do you do that? If you write Windows libraries, you have to dllexport stuff, however GCC 4 supports the same feature, there you have to use visibility(default) stuff. There is something about this in the libtool manual (section 11.2): That is if I prepend something_LTX_ before the symbol name, the symbol becomes 'external'. However I have the impression that this is an extra layer and that I still have to take care of visibility like I have to when dealing with shared libraries. Probably with one exception, Windows uses dllimport to use shared lib functions, but this doesn't make sense to me in case of modules... Is that right? If yes, maybe it could be mentioned in the manual. Regards, Matej ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: lt_dlerror 'file not found' bug
On Sun, 13 Dec 2009, Matěj Týč wrote: What I have thought of is stopping any attempt to open any new module filename if the previous attempt has failed for another reason that because the file wasn't there. Do you think this is a good assumption? The problem is that libltdl supports several different types of loaders and every available type of loader is used. So (as you say) the last loader used is the one which produces the final error. The first loader type which is always used is the preloader, which tries to load a static implementation from a library and a library which uses shared modules will usually fail the preloader. The preloader likely also pretends that the file is not there if there is no preloadable module. The bug you are encountering was reported at least two years ago. It is still awaiting a good idea for how to fix it. There needs to be some notion of error priority so that the error with the most priority gets saved. 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: lib seach path
* 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. Cheers, Ralf ___ http://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
