Re: macros for rpath support

2002-05-22 Thread Bruno Haible
Paul Eggert asks: > First, can you write up some documentation for it, suitable for use > in the Autoconf manual? Sure. But first I'd like to know Akim's opinion in general. Bruno

Re: macros for rpath support

2002-05-22 Thread Bruno Haible
Henrique de Moraes Holschuh asks: > is it easy to _disable_ such feature? We have our own reasons for > not wanting rpath information in our Debian packages Yes. You simply specify --prefix=/nonexistent at configuration time. At installation time you use "make install DESTDIR=/tmp/destdir" and

Re: macros for rpath support

2002-05-22 Thread Henrique de Moraes Holschuh
On Wed, 22 May 2002, Bruno Haible wrote: > > is it easy to _disable_ such feature? We have our own reasons for > > not wanting rpath information in our Debian packages > > Yes. You simply specify --prefix=/nonexistent at configuration time. > At installation time you use "make install DESTDIR=/t

Re: macros for rpath support

2002-05-22 Thread Bruno Haible
Henrique de Moraes Holschuh writes: > This is very un-optimal. Some programs embed the prefix path to find other > files, and those would break quite hard. Oh, I gave an advice suitable for building relocatable binary packages. If that's not what you are doing, then please, can you tell why you

Re: Site Macro Directory

2002-05-22 Thread Mark D. Roth
Barring any further input from anyone, it seems like we've reached a consensus on this proposal. The final version is included below. Paul or Akim, can one of you tell me how to procede with this? Should I submit a patch, or would you prefer to implement these changes yourselves? Thanks for th

Re: macros for rpath support

2002-05-22 Thread Henrique de Moraes Holschuh
On Wed, 22 May 2002, Bruno Haible wrote: > Henrique de Moraes Holschuh writes: > > This is very un-optimal. Some programs embed the prefix path to find other > > files, and those would break quite hard. > > Oh, I gave an advice suitable for building relocatable binary > packages. If that's not wh

Re: macros for rpath support

2002-05-22 Thread Alexandre Duret-Lutz
>>> "Henrique" == Henrique de Moraes Holschuh <[EMAIL PROTECTED]> writes: [...] Henrique> We use ld.so.conf and the ld.so linker itself only, Wouldn't it be enough to teach `config.rpath' to *not* output `-rpath DIR' when `DIR' is already searched by `ld.so'? Like Libtool does (see `$sys_lib_

Re: macros for rpath support

2002-05-22 Thread Henrique de Moraes Holschuh
On Wed, 22 May 2002, Alexandre Duret-Lutz wrote: > >>> "Henrique" == Henrique de Moraes Holschuh <[EMAIL PROTECTED]> writes: > Henrique> We use ld.so.conf and the ld.so linker itself only, > > Wouldn't it be enough to teach `config.rpath' to *not* output > `-rpath DIR' when `DIR' is already sea

Re: macros for rpath support

2002-05-22 Thread Bruno Haible
Henrique de Moraes Holschuh writes: > I am not doing anything of the sort. We are usually downstream maintainers > in Debian. But lots of upstream autoconf scripts use $prefix to set the > default path for modules ... > > As for rpath in the distribution: We don't want rpath because rpath kills

Re: macros for rpath support

2002-05-22 Thread Bruno Haible
Alexandre Duret-Lutz writes: > Wouldn't it be enough to teach `config.rpath' to *not* output > `-rpath DIR' when `DIR' is already searched by `ld.so'? > Like Libtool does (see `$sys_lib_search_path'). The AC_LIB_LINKFLAGs macro does not output '-rpath DIR' when DIR is an apparent known director

[autoconf] Cray Fortran compilers

2002-05-22 Thread Kate Hedstrom
Can I request that cf77 and cft77 get removed from the list of Fortran compilers to try? They are both old and I was surprised to find them on the system. Neither one passes the configure tests while f90 (for years the recommended compiler) does: % uname -a sn3306 chilkoot 10.0.1.0 jlm.3 CRAY SV1

RE: macros for rpath support

2002-05-22 Thread Dan Kegel
Henrique de Moraes Holschuh wrote: > Many of our porters hate libtool with vengeance (or worse) I certainly do. As a guy who routinely cross-compiles applications for embedded systems, I can testify that libtool is a broken pain in the ass sometimes. - Dan

Re: Site Macro Directory

2002-05-22 Thread Mark D. Roth
On Wed May 22 10:36 2002 -0500, Mark D. Roth wrote: > Barring any further input from anyone, it seems like we've reached a > consensus on this proposal. The final version is included below. Actually, I just realized that using a single include macro to handle both the local files and the system-

Re: macros for rpath support

2002-05-22 Thread Henrique de Moraes Holschuh
On Wed, 22 May 2002, Bruno Haible wrote: > OK, I see. You are building non-relocatable packages in general, but > still want libraries to be relocatable in case of major system > surgery, and the /etc/ld.so.conf file is completely satisfactory for > your purpose. Right? Yes. > I think a configur

Re: Site Macro Directory

2002-05-22 Thread Paul Eggert
> From: "Mark D. Roth" <[EMAIL PROTECTED]> > Date: Wed, 22 May 2002 13:56:33 -0500 > > * autoconf's search path should be: > 1. the current directory (i.e., $top_srcdir) But the current directory is not top_srcdir in all cases. E.g. an include file in one directory might include another.

LIBOBJ problems

2002-05-22 Thread Matias Atria
Hi, I noticed that setting LIBOBJS manually in 2.53 now produces an error, but I think the way this is implemented goes a bit too far: $ cat configure.ac AC_INIT test -z "$LIBOBJS" $ autoconf configure.ac:2: error: do not use LIBOBJS directly, use AC_LIBOBJ [...] I don't think examining (witho

Re: Site Macro Directory

2002-05-22 Thread Mark D. Roth
On Wed May 22 15:50 2002 -0700, Paul Eggert wrote: > On Wed, 22 May 2002 13:56:33 -0500, Mark D. Roth wrote: > > * autoconf's search path should be: > > 1. the current directory (i.e., $top_srcdir) > > But the current directory is not top_srcdir in all cases. > E.g. an include file in one

Re: Site Macro Directory

2002-05-22 Thread Mark D. Roth
On Wed May 22 21:40 2002 -0500, Mark D. Roth wrote: > On Wed May 22 15:50 2002 -0700, Paul Eggert wrote: > > My own reaction is positive, but I would suggest that you write up the > > proposal, as a proposed patch to the manual. (Often the documentation > > is the hardest to write, so perhaps it'