Hi Jan, Il giorno 09/dic/07, alle ore 22:33, Jan Beyer ha scritto:
Leo "costela" Antunes schrieb am 06.12.2007 16:32 Uhr:I had to do the option for a patch on aclocal.m4 and configure scripts with dpatch on build-time. On aclocal4 and configure the changes are (for each occurrence): - hardcode_into_libs=yes + hardcode_into_libs=no -hardcode_into_libs=$hardcode_into_libs +hardcode_into_libs=noI haven't looked into your case, but unless I'm mistaken you shouldn't need to patch aclocal.m4 if you're already patching the configure script. You should either patch aclocal.m4 in case the configure script will be re-generated on build-time (which is unlikely your case) or patch the configure script directly. Or am I missing something?I can only say, I replaced 30 occurences of the upper and threeoccurences of the lower change in my package's configure script (packagegwyddion). This patch gets applied correctly and the lines in the configure script read correctly hardcode_into_libs=no.Still, the linker gets the --rpath /usr/lib option passed and the rpathgets built in... :-( I'll investigate further, just wanted to share this... Any news on your side, Francesco?
Hi Jan, in this period I'm very busy, I haven't tested the patch to aclocal.m4,the only test that I've done last week has been the patch of libtool after
the call of ./configure... The one proposed in the wiki page , by Marcelo Magallon, in this way you get all the calls to "--rpath" to "-D__LIBTOOL_IS_A_FOOL__" :),I don't know if it's a bad or good solution, my original question on this thread
was this one...Consider that you can restrict the patch of libtool only to 64 bit architectures...
Hope this helps. Cheers, francesco  http://wiki.debian.org/RpathIssue -- Francesco Namuri francesco(at)namuri(dot)it http://namuri.it/ id gpg key: 21A4702A firstname.lastname@example.org
Description: This is a digitally signed message part