Re: [Cooker] Re: [CHRPM] php-4.3.3-2mdk
On Wed, 3 Sep 2003, Ben Reser wrote: On Wed, Sep 03, 2003 at 09:05:53AM +0200, Gwenole Beauchesne wrote: I explained. If encoded RPATH concerned X11 libs, update their aclocal.m4 (LIBTOOL) with bits from system's to add x11 libs in skip list. You said it should be possible. How about providing the bits (as you put it) to do just that. gc's patch. ;-) Something like the following applied to aclocal.m4 or acinclude.m4 if you intend to regenerate the former: @@ -1932,8 +1932,8 @@ shlibpath_overrides_runpath=unknown version_type=none dynamic_linker=$host_os ld.so -sys_lib_dlsearch_path_spec=/lib /usr/lib -sys_lib_search_path_spec=/lib /usr/lib /usr/local/lib +sys_lib_dlsearch_path_spec=/lib /usr/lib /usr/X11R6/lib +sys_lib_search_path_spec=/lib /usr/lib /usr/local/lib /usr/X11R6/lib case $host_os in aix3*) Besides, configure seems to list: --disable-rpath Disable passing additional runtime library search paths doesn't it work? Or hell even better, why don't you just fix chrpath as Debian did to work right on 64-bit archs? Done, but I'd still prefer the right disabling of rpath without using chrpath. I once saw a null DT_RPATH entry, it looks weird... Bye, Gwenole.
Re: [Cooker] Re: [CHRPM] php-4.3.3-2mdk
On Thu, Sep 04, 2003 at 04:09:28PM +0200, Gwenole Beauchesne wrote: gc's patch. ;-) Something like the following applied to aclocal.m4 or acinclude.m4 if you intend to regenerate the former: @@ -1932,8 +1932,8 @@ shlibpath_overrides_runpath=unknown version_type=none dynamic_linker=$host_os ld.so -sys_lib_dlsearch_path_spec=/lib /usr/lib -sys_lib_search_path_spec=/lib /usr/lib /usr/local/lib +sys_lib_dlsearch_path_spec=/lib /usr/lib /usr/X11R6/lib +sys_lib_search_path_spec=/lib /usr/lib /usr/local/lib /usr/X11R6/lib case $host_os in aix3*) I'll see if this works... Besides, configure seems to list: --disable-rpath Disable passing additional runtime library search paths doesn't it work? On the packages that I've used chrpath on it didn't. :( Done, but I'd still prefer the right disabling of rpath without using chrpath. I once saw a null DT_RPATH entry, it looks weird... Agreed, but I'd rather get rid of the rpath sooner rather than later... If I have to use chrpath as a hack to get the package out without an rpath that's better than a package with an rpath or no package because I don't have the time to fix the broken build system. :) -- Ben Reser [EMAIL PROTECTED] http://ben.reser.org What upsets me is not that you lied to me, but that from now on I can no longer believe you. -- Nietzsche
Re: [Cooker] Re: [CHRPM] php-4.3.3-2mdk
On Tue, 2 Sep 2003, Ben Reser wrote: Rather than just bitching provide an explanation of how to avoid using chrpath and we'll try and fix the packages so they don't use it. I explained. If encoded RPATH concerned X11 libs, update their aclocal.m4 (LIBTOOL) with bits from system's to add x11 libs in skip list. Incidentally, what's non-portable about chrpath? I thought it would work on any ELF binary? elf32 binaries.
Re: [Cooker] Re: [CHRPM] php-4.3.3-2mdk
On Wed, Sep 03, 2003 at 09:05:53AM +0200, Gwenole Beauchesne wrote: I explained. If encoded RPATH concerned X11 libs, update their aclocal.m4 (LIBTOOL) with bits from system's to add x11 libs in skip list. You said it should be possible. How about providing the bits (as you put it) to do just that. I'm not terribly familiar with autoconf and libtool. You apparently are. Rather than me spending hours trying to figure out how to fix things from your vague direction, why don't you just show me an example. Or even hell point me at some documentation that has a reasonable example. elf32 binaries. It's funny that you assume we know that since I can't find a shred of documentation that comes with the package that mentions that... After a little bit of digging it looks like Debian has run into this issue: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=197210 http://ftp.debian.org/debian/pool/main/c/chrpath/chrpath_0.10-2.diff.gz Looks like Debian has patched chrpath to work fine on elf64... I don't have a 64-bit machine that Mandrake will run on. I don't mind fixing things for 64-bit. Rather than sending nasty grams assuming we know what issues apply to 64-bit archs that most of us don't have access to... It'd be useful if you were a little more diplomatic about it. Or hell even better, why don't you just fix chrpath as Debian did to work right on 64-bit archs? -- Ben Reser [EMAIL PROTECTED] http://ben.reser.org What upsets me is not that you lied to me, but that from now on I can no longer believe you. -- Nietzsche
Re: [Cooker] Re: [CHRPM] php-4.3.3-2mdk
On Wed, Aug 27, 2003 at 07:14:49AM +0200, Gwenole Beauchesne wrote: Hi, -=-=-=- Name: php Relocations: (not relocateable) Version : 4.3.3 Vendor: MandrakeSoft Release : 2mdk Build Date: Wed Aug 27 02:13:47 2003 -=-=-=- - php-devel should require openssl-devel (buchan?) - drop php-killrpath (S1), use chrpath instead Why do people keep on using this non portable tool? It should be possible to import our libtool to aclocal.m4 so that RPATH to X11 libs is not generated. Rather than just bitching provide an explanation of how to avoid using chrpath and we'll try and fix the packages so they don't use it. Incidentally, what's non-portable about chrpath? I thought it would work on any ELF binary? -- Ben Reser [EMAIL PROTECTED] http://ben.reser.org What upsets me is not that you lied to me, but that from now on I can no longer believe you. -- Nietzsche
[Cooker] Re: [CHRPM] php-4.3.3-2mdk
Hi, -=-=-=- Name: php Relocations: (not relocateable) Version : 4.3.3 Vendor: MandrakeSoft Release : 2mdk Build Date: Wed Aug 27 02:13:47 2003 -=-=-=- - php-devel should require openssl-devel (buchan?) - drop php-killrpath (S1), use chrpath instead Why do people keep on using this non portable tool? It should be possible to import our libtool to aclocal.m4 so that RPATH to X11 libs is not generated. Bye, Gwenole
