Re: Version numbering
Daniel Reed [EMAIL PROTECTED] wrote: Several GNU projects (including GCC) do leave off .0's for anything past the minor number, so it seems ls -v can't be the final authority :/ It does not follow that this numbering scheme is a good one. I would argue that it isn't. The gcc maintainers seemed to be willing to add .0, but the request didn't come in time for 3.3. paul ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: LD_RUN_PATH not adding paths when building with shared libs
Bill Moseley [EMAIL PROTECTED] wrote: So, it seems like the LD_RUN_PATH path is not used when building our project unless we use --disable-shared: I'm not especially familiar with libtool, but IME, LD_RUN_PATH is ignored if any run-time search directories are given on the command line. So if the command that links your binary has any -Wl,-R, options (or whatever they look like on your platform), that may be the problem. (By the way, I'm sure I used to know a better way to show the search path for a binary than using strings!) At least with GNU binutils: objdump -p | grep RPATH paul ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: Creating lock file for compilers that don't support -c -o
Bob Friesenhahn [EMAIL PROTECTED] wrote: Creating a hard link is an atomic operation whereas a symbolic link is not How so? paul ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: Creating lock file for compilers that don't support -c -o
Bob Friesenhahn [EMAIL PROTECTED] wrote: Creating a symbolic link requires testing for an existing file, and then (if the file does not exist) creating a new file, and a directory entry to reference it. This requires multiple network transactions with an opportunity for race-conditions. open() with O_CREAT|O_EXCL also creates a new file, yet that does not subject it to race conditions. symlink() has equivalent semantics to O_CREAT|O_EXCL. It may be that some network filesystems fail to preserve the atomicity; I wouldn't know. But at least for local filesystems, I don't see any problems with symlinks. paul ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
libc is somewhere else
On my custom-built GNU/Linux systems, glibc is not installed in the usual place. Passing the appropriate -I, -L, and -Wl,-R, flags is often enough to build most things. I've found some additional problems with libtool-based packages, though. - Some (older?) versions of ltconfig look for /lib/libc*. I can patch ltconfig before building to solve this. - The *_path_spec variables don't include my glibc directory. I see code in ltconfig that suggests that my -L/-Wl,-R, directories are supposed to be noticed and added to those variables, but I'm not really sure what the intended behavior is. Should I patch this too? Are there any other places where a libtool-based package would expect libc to be in a certain place? Must I patch them all, or is there an environment setting, etc., that I could use to tell libtool where my libc is? paul ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: use of libtool for linking executables - rpath problem
Rob Browning [EMAIL PROTECTED] wrote: Bruno Haible [EMAIL PROTECTED] writes: 3) Introduce a libintl-config script that sets outputs the right -L and -rpath option. This may or may not help you if you're linking with *any* other tools that are installed in /usr/lib and their foo-config scripts output -L/usr/lib. In that case you *cannot* in general be assured of linking against a locally installed version of libintl whenever you also have another version (including the development .so links) installed in /usr/lib. The one in /usr/lib, if the other package's -L/usr/lib comes first, will take prececence. Uh? AIUI, the basename of the shared library is embedded in the executable, but not the full path. The library is searched for first in the -rpath directories (also embedded in the executable) and then in the global directories such as /usr/lib. As a side note, it'd be nice if specifying the full path to a shared library on the ld command line would cause the full path to be embedded in the executable so no searching would be necessary. The ELF spec seems to allow this. I doubt anyone uses full paths to shared libraries currently, but if we want to worry about that, we could introduce a new flag to turn on this behavior. paul ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
