Re: Bug in libtoolize
On Feb 16, 2005, at 9:28 AM, Peter O'Gorman wrote: | Some suggestions for a fix: | | 1. Do the copy as now, but then have a series of "touch" statements to | modify the mtime/ctime all the relevant AM-specific files in the Right | Order so that the timestamps will be proper. | | 2. Copy the files over in order in the first place (i.e., don't use a | glob). | | 3. Tar up the source directory and untar it in the destination. | | Each of the three has benefits and drawbacks -- I guess I'd lean towards | #1. It's probably the least elegant, but it guarantees to get it Right | with the least amount of work. Everyone else seems to be on holiday, so I guess I'll look into it (unless you want to send a patch? :-).) Could libtoolize just use 'cp -f -p' instead of 'cp -f' when copying the files and leave the timestamps as they are in the original libltdl directory? I admit to not understanding all the details, but that was enough to clear up the problem for me (as one would expect - the installed sources of libltdl should be setup correctly...). Seems much easier than any of the other options. Brian -- Brian Barrett Graduate Student, Open Systems Lab, Indiana University http://www.osl.iu.edu/~brbarret/ ___ http://lists.gnu.org/mailman/listinfo/libtool
multilib
Hi,
I'm not really too knowledgable of the problem space. What are the problems
with multilib? Is it just that libtool searches the wrong libdirs?
/usr/lib64 should come before /usr/lib? If that is the case, then surely it
can be fixed fairly simply by changing our reliance on 'gcc
-print-search-dirs' to something else (as gcc -print-search-dirs currently
tells lies in the multilib case).
For example, I have the following script (no code comments please, this is
just messing about):
$ cat testscript.sh
#! /bin/sh
: ${CC=gcc}
echo "int main(){return 0;}" > conftest.c
args=`$CC -v conftest.c -o conftest 2>&1`
rm -f conftest conftest.c
mylist=
for arg in $args
do
case $arg in
-L*) realdir=`echo $arg |sed -e 's/^-L//'`
realdir="`cd $realdir && pwd`"
case " $mylist " in
*" $realdir "*) ;;
*) mylist="$mylist $realdir";;
esac
;;
esac
done
echo $mylist
And when I run it (on a sourceforge FC3 compile farm host):
$ sh ./testscript.sh
/usr/lib/gcc/x86_64-redhat-linux/3.4.2 /usr/lib64
$ env CC='gcc -m32' sh ./testscript.sh
/usr/lib/gcc/x86_64-redhat-linux/3.4.2/32
/usr/lib/gcc/x86_64-redhat-linux/3.4.2 /usr/lib /lib
Couldn't we simply replace occurences of 'gcc -print-search-dirs' with some
code like the above in libtool.m4 to get a more reasonable value for
sys_lib_search_path_spec. As I said, I have not got a true understanding of
the problem. So please help me to understand it more :)
Peter
--
Peter O'Gorman - http://www.pogma.com
___
http://lists.gnu.org/mailman/listinfo/libtool
Re: Bug in libtoolize
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jeff Squyres wrote: | I have found a bug in libtoolize which has bit me for a long, long time | but I've never gotten around to checking it out (it was a minor | annoyance). But today, it bit one of my other developers in a rather | awkward moment. So I guess it's time to investigate and report this | bug. :-) Real bug, thanks for finding/reporting it. | Some suggestions for a fix: | | 1. Do the copy as now, but then have a series of "touch" statements to | modify the mtime/ctime all the relevant AM-specific files in the Right | Order so that the timestamps will be proper. | | 2. Copy the files over in order in the first place (i.e., don't use a | glob). | | 3. Tar up the source directory and untar it in the destination. | | Each of the three has benefits and drawbacks -- I guess I'd lean towards | #1. It's probably the least elegant, but it guarantees to get it Right | with the least amount of work. Everyone else seems to be on holiday, so I guess I'll look into it (unless you want to send a patch? :-).) Peter - -- Peter O'Gorman - http://www.pogma.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.6 (Darwin) iQCVAwUBQhNYkLiDAg3OZTLPAQJ5+wP/epyt2+PhA/v7Ij+Ys9lVAYIkUmsmEirZ nlfsd58W1u1uoO0JJ6BygH7ErOgddNah7vMThgRtQJIJw8Dc0Nkj0eEUg906xemF yBbIKn4Qh/d24g6MBHr9h9e/VZGo3fZPiE3Q6s6gVz4OSFV/6sTLi7kDtXVwBPL0 CaKndot/iVo= =Bk9r -END PGP SIGNATURE- ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Bug in libtoolize
Brian Barrett wrote: Could libtoolize just use 'cp -f -p' instead of 'cp -f' when copying the files and leave the timestamps as they are in the original libltdl directory? I admit to not understanding all the details, but that was enough to clear up the problem for me (as one would expect - the installed sources of libltdl should be setup correctly...). Seems much easier than any of the other options. I'm just googling cp -p portability actually, on first inspection it seems like this is a no-brainer. I'll google some more to find out why we're wrong :) Peter -- Peter O'Gorman - http://www.pogma.com ___ http://lists.gnu.org/mailman/listinfo/libtool
$ORIGIN on various platforms
Hi, On Solaris and Linux platforms the $ORIGIN variable as RPATH is supported and is working. For AIX '$ORIGIN/../lib' is part of the '-blibpath:' option and after compiling and linking, Using objdump, I see the $ORIGIN../lib in the RPATH section, but still it is not able to find the libraries during execution, it seems that it is not able to resolve $ORIGIN On HPUX, the libraries get resolved only if the complete binary path is entered during execution, here again seems like it is not able to resolve the $ORIGIN variable! Is $ORIGIN supported on HPUX and AIX platforms? Any relevant links on the subject would be helpful. Thanks -KPRajesh ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Bug in libtoolize
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Peter O'Gorman wrote: | I'm just googling cp -p portability actually, on first inspection it | seems like this is a no-brainer. I'll google some more to find out why | we're wrong :) If you're in a timezone that is currently awake, send a patch to -patches, I'm off to bed. This looks fine to me. If you don't send a patch, I'll make one tomorrow. Thanks, Peter - -- Peter O'Gorman - http://www.pogma.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.6 (Darwin) iQCVAwUBQhNiHLiDAg3OZTLPAQJkNAP9FWwnlHrwrbXMr6kE3mZyHUuYWYBRGxHT 6QZvjka1VFdLwafWZprEHH1bCN28Nq6EeEnFZYp9hXth7DBenC7V/WL6gjOjuj+4 qTaOOkjsffU6jGjRIdbcEIQmhgjWYHpTlVAaGfX+EVxZmhW8yiW/qhBk1iXtW5Fl TbL956C3rr0= =6z0/ -END PGP SIGNATURE- ___ http://lists.gnu.org/mailman/listinfo/libtool
How new Check 21 legislation is affecting you...
Good Afternoon! Recenty intrdocuced legislation requires business and home users to print personal and business checks with security blank check stock and magnetic ink. Please find qualified suppliers at Google by clicking on the followingl link. http://www.google.com/search?sourceid=navclient&ie=UTF-8&rls=GGLC,GGLC:1969-53,GGLC:en&q=blank+check+paper%2C+magnetic+ink+for+inkjets Thank you very much. Cathleen Baer Marketing & Relationship Representative Globalzon Consulting Group ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: multilib
[ please forgive the webmailer messing up the lines ] Peter O'Gorman writes: I'm not really too knowledgable of the problem space. What are the problems with multilib? Is it just that libtool searches the wrong libdirs? That's one of them. Libtool aims out to do the same thing the linker does. However, GNU ld skips over 32bit libraries (without erroring out) when searching or a 64bit one. (This is just one example.) /usr/lib64 should come before /usr/lib? If that is the case, then surely it can be fixed fairly simply by changing our reliance on 'gcc -print-search-dirs' to something else (as gcc -print-search-dirs currently tells lies in the multilib case). Yes, to a certain extent. For example, I have the following script (no code comments please, this is just messing about): *snip* realdir="`cd $realdir && pwd`" *snip* And when I run it (on a sourceforge FC3 compile farm host): $ sh ./testscript.sh /usr/lib/gcc/x86_64-redhat-linux/3.4.2 /usr/lib64 $ env CC='gcc -m32' sh ./testscript.sh /usr/lib/gcc/x86_64-redhat-linux/3.4.2/32 /usr/lib/gcc/x86_64-redhat-linux/3.4.2 /usr/lib /lib Now try to do the same thing with intended DESTDIR. (This might in fact work.) But now try to do the same thing with /opt/lib in gcc's search path and /opt being a symlink to a path which is not constant on all hosts on which the NFS volume is mounted. (This might work if you use `pwd -L'. That is not portable, however. We might say that we do not care about preserving logical paths with such systems.) Couldn't we simply replace occurences of 'gcc -print-search-dirs' with some code like the above in libtool.m4 to get a more reasonable value for sys_lib_search_path_spec. As I said, I have not got a true understanding of the problem. So please help me to understand it more :) Well, maybe we really should not try to solve the several problems at once. I don't know. But I have a kind of bad feeling committing to new solutions which do not work well with cross-compiling, for example. Cheers, Ralf (doing only sparse email reading ATM) ___ http://lists.gnu.org/mailman/listinfo/libtool
