Hello,
Here's a diff against the CVS trunk to address an issue on FreeBSD.
FreeBSD apparently shares with OpenBSD that -lc should not be
explicitly linked in. We've tested the equivalent change made
against libtool 1.4.2.
Can someone pick up this fix? Thanks!
- Don Anderson
Index: ChangeLog
Dear libtool gurus,
More and more GNU packages start using shared libraries. One example is
libintl (from the GNU gettext package), which installs itself as a shared
library by default now. It is used by many other packages, like textutils,
gcc, hello, and others, which don't use libtool.
For u
>I can see six possible approaches:
The 7th is to have the shared library use pkg-config, allowing other
tools to find out about it without relying on the linker configuration.
Its much cleaner than any of the other choices you mention, and
thankfully, has nothing to do with libtool (phew!)
--p
Bruno Haible <[EMAIL PROTECTED]> writes:
> 3) Introduce a libintl-config script that sets outputs the right -L and
>-rpath option.
This may or may not help you if you're linking with *any* other tools
that are installed in /usr/lib and their foo-config scripts output
-L/usr/lib.
In that cas
Rob Browning <[EMAIL PROTECTED]> wrote:
> Bruno Haible <[EMAIL PROTECTED]> writes:
>> 3) Introduce a libintl-config script that sets outputs the right -L and
>>-rpath option.
>
> This may or may not help you if you're linking with *any* other tools
> that are installed in /usr/lib and their fo
Paul Davis writes:
> The 7th is to have the shared library use pkg-config, allowing other
> tools to find out about it without relying on the linker configuration.
> Its much cleaner than any of the other choices you mention, and
> thankfully, has nothing to do with libtool (phew!)
Can you pleas
>> The 7th is to have the shared library use pkg-config, allowing other
>> tools to find out about it without relying on the linker configuration.
>> Its much cleaner than any of the other choices you mention, and
>> thankfully, has nothing to do with libtool (phew!)
>
>Can you please elaborate mo
On Mon, 19 Nov 2001, Bruno Haible wrote:
> 3) Introduce a libintl-config script that sets outputs the right -L and
>-rpath option.
Most packages appear to select this option. Unfortunately it is often
worse than useless because it only works in the most simplistic case
--- the case where th
Bob Friesenhahn <[EMAIL PROTECTED]> wrote:
> What is needed is a "database" which acts as a registry of installed
> packages. This would be updatable by 'make install' as well as
> binary packaging tools.
http://cr.yp.to/slashpackage.html>
> A tool would be provided to formulate the optimum -I,
On Mon, Nov 19, 2001 at 11:15:37AM +0100, Lutz Müller wrote:
> Hi Gary,
>
> where should I ask for an lt_dlforeachfile function that actually scans
> a directory when called a second time?
The libtool list <[EMAIL PROTECTED]> is the best place. However, I guess
I am not understanding your quest
Support Request #100207, was updated on 2001-Nov-19 13:18
You can respond by visiting:
http://savannah.gnu.org/support/?func=detailsupport&support_id=100207&group_id=25
Category: None
Status: Open
Priority: 5
Summary: need_lib_prefix=no for osf*
By: bs
Date: 2001-Nov-19 13:18
Message:
Logged I
> From: Bruno Haible <[EMAIL PROTECTED]>
> Date: Mon, 19 Nov 2001 19:08:59 +0100 (CET)
>
> 1) We don't change our packages. We only tell the user that he should have
>used LDFLAGS="-L${prefix}/lib -rpath ${prefix}/lib"
>
> 6) Let each package search for 'libtool' in $PATH and use it if f
Paul Eggert writes:
> > 6) Let each package search for 'libtool' in $PATH and use it if found,
> >and fall back to 1) if not found
> >
> >This works only when the same C compiler is used to build the package
> >as was used to configure libtool.
>
> Can you please explain why (6)
>What is needed is a "database" which acts as a registry of installed
>packages. This would be updatable by 'make install' as well as binary
>packaging tools.
all of GNOME is now using pkg-config for this purpose.
> A tool would be provided to formulate the optimum
>-I, -L, a
[EMAIL PROTECTED] (Paul Jarc) writes:
> Uh? AIUI, the basename of the shared library is embedded in the
> executable, but not the full path. The library is searched for first
> in the -rpath directories (also embedded in the executable) and then
> in the global directories such as /usr/lib.
Th
Support Request #100207, was updated on 2001-Nov-19 18:18
You can respond by visiting:
http://savannah.gnu.org/support/?func=detailsupport&support_id=100207&group_id=25
Category: None
Status: Open
Priority: 5
Summary: need_lib_prefix=no for osf*
By: enchanter
Date: 2001-Nov-19 21:52
Message:
L
On Mon, 19 Nov 2001, Paul Davis wrote:
> >What is needed is a "database" which acts as a registry of installed
> >packages. This would be updatable by 'make install' as well as binary
> >packaging tools.
>
> all of GNOME is now using pkg-config for this purpose.
>
> >A tool w
>> pkg-config doesn't do that. its an almost impossible task unless you
>
>Are you talking about some new tool that I had not previously heard
>about or are you talking about a script like the
>'/usr/local/bin/gnome-config' I see on my system?
its a replacement for *all* such scripts. its a C p
Rob Browning <[EMAIL PROTECTED]> writes:
> The problem I'm talking about is if Makefile.am's use
> LDFLAGS = `gnome-config --libs foo` `foo-config --libs bar`
> then if you've got a normal gnome-dev package installed, such that
> it's libs are in /usr/lib, it will (or at least it used to) put
On 19 Nov 2001, Russ Allbery wrote:
> Rob Browning <[EMAIL PROTECTED]> writes:
>
> > The problem I'm talking about is if Makefile.am's use
>
> > LDFLAGS = `gnome-config --libs foo` `foo-config --libs bar`
>
> > then if you've got a normal gnome-dev package installed, such that
> > it's libs
Bob Friesenhahn <[EMAIL PROTECTED]> writes:
> How is the application developer to know which directories are searched
> by default?
One can safely assume that /usr/lib and /usr/include are always searched
by default. Those are the only ones that I'd expect people to
automatically leave out of t
21 matches
Mail list logo
