The "GNU build system" has a solution for _building_ shared libraries
portably, namely libtool. As paradoxical as it sounds, it does not yet
have a solution for _using_ shared libraries portably.
The linker command line for using a shared library is fortunately the
same everywhere on Unix, namel
On Tue, 21 May 2002, Bruno Haible wrote:
> So I set out and realized in gettext-0.11.2 a solution of the LD_LIBRARY_PATH
[...]
Weird as it may sound, is it easy to _disable_ such feature? We have our
own reasons for not wanting rpath information in our Debian packages (which
are beyond the scope
> From: Bruno Haible <[EMAIL PROTECTED]>
> Date: Tue, 21 May 2002 14:45:46 +0200 (CEST)
>
> I would propose this facility for inclusion in GNU autoconf. The reason is
> that although it has been developed to deal with -lintl and -liconv, the
> macros are generally useful and can equally well be u
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
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
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
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
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
>>> "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_
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
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
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
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
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
Thanks Bruno,
This is a very welcome addition to Autoconf. As a matter of fact,
some users had already suggested that we swallow your macros, and Paul
had suggested that we wait until you feel it is mature enough.
It seems that this day has come!
There remains mostly details to settle: the co
> From: Akim Demaille <[EMAIL PROTECTED]>
> Date: 26 May 2002 12:00:27 +0200
>
> For safety, it would be good that we have two different macro names.
I don't see why it's safer to have two different macro names. I've
often redefined Autoconf-supplied macros with no ill effects, and I
presume a
> "Paul" == Paul Eggert <[EMAIL PROTECTED]> writes:
>> From: Akim Demaille <[EMAIL PROTECTED]> Date: 26 May 2002 12:00:27
>> +0200
>>
>> For safety, it would be good that we have two different macro
>> names.
Paul> I don't see why it's safer to have two different macro names.
Paul> I've oft
Akim Demaille writes:
> This is a very welcome addition to Autoconf.
Nice to hear :-)
> There remains mostly details to settle: the code will be tranformed
> for 2.54, which basically means that 2.13 compatibility stuff will be
> removed.
Fine with me.
> Since you keep backward compatibility,
On Mon, May 27, 2002 at 02:56:57PM +0200, Bruno Haible wrote:
> I recommend using aclocal-1.5 or newer, then there are no safety
> issues.
it would be nice if one or both of autoconf and automake would document the
version requirements relative to the other.
--
Thomas E. Dickey <[EMAIL PROTECTE
> "Bruno" == Bruno Haible <[EMAIL PROTECTED]> writes:
Bruno> Akim Demaille writes:
>> This is a very welcome addition to Autoconf.
Bruno> Nice to hear :-)
Everybody I know who looked at your work was positively impressed.
I still have one question though: how would you rate the impedance
> "Thomas" == Thomas Dickey <[EMAIL PROTECTED]> writes:
Thomas> On Mon, May 27, 2002 at 02:56:57PM +0200, Bruno Haible wrote:
>> I recommend using aclocal-1.5 or newer, then there are no safety
>> issues.
Thomas> it would be nice if one or both of autoconf and automake would
Thomas> document
Akim Demaille writes:
> I still have one question though: how would you rate the impedance
> there is between this macro and config.rpath ot1h side and Libtool
> otoh? I especially interested in knowing whether what learns one of
> the community should be reported to the other.
The variables de
> "Bruno" == Bruno Haible <[EMAIL PROTECTED]> writes:
Bruno> Akim Demaille writes:
>> I still have one question though: how would you rate the impedance
>> there is between this macro and config.rpath ot1h side and Libtool
>> otoh? I especially interested in knowing whether what learns one
>
Akim Demaille writes:
> Bruno> The variables determined by config.rpath are a subset of those
> Bruno> determined by libtool.m4. Therefore config.rpath should be
> Bruno> updated according to modifications made in official libtool
> Bruno> releases. (But it doesn't hurt verifying the settings usin
(Flsuhing old messages :)
I'll steal these macros from 0.11.3.
25 matches
Mail list logo
