[EMAIL PROTECTED] writes:
> Ick! If anything, pkg-config should use libtool. I don't think libtool
> should *depend* on pkg-config at all. Libtool might be enhanced to
> help pkg-config get at certain data but I hope it does no more than
> that. That said, *.la files are already easy to parse.
Alexandre Oliva <[EMAIL PROTECTED]> writes:
>
> You wouldn't. This is totally out of the scope of libtool. Libtool
> is about linking with libraries, not compiling source files so that
> they can be linked with them. Not that it couldn't be extended so as
> to record user-directed flags at th
Alexandre Oliva <[EMAIL PROTECTED]> writes:
> On Apr 22, 2001, Havoc Pennington <[EMAIL PROTECTED]> wrote:
>
> > pkg-config has some intelligence, i.e. if you request two libs at once
> > it will nuke duplicate flags and order the -l flags properly.
>
> Err... It won't always remove duplicate
Martijn van Beers wrote:
> On Sun, Apr 22, 2001 at 07:34:42AM -0300, Alexandre Oliva wrote:
> > On Apr 22, 2001, Eric Lemings <[EMAIL PROTECTED]> wrote:
> >
> >> Currently, they just install their .pc file into pkg-config's data directory.
> > Which is exactly the wrong approach. A package shoul
On Sun, Apr 22, 2001 at 01:19:03PM +0200, Peter Eisentraut wrote:
> Albert Chin-A-Young writes:
>
> > Because of this, the following code snippet in ltmain.in will always
> > fail (and thus 'make uninstall' will always fail on Solaris):
> > # Don't error if the file doesn't exist and rm -f was
On Sun, Apr 22, 2001 at 07:54:30AM -0300, Alexandre Oliva wrote:
> On Apr 22, 2001, [EMAIL PROTECTED] wrote:
>
> > Patch below to override the fgrep test for IRIX 6.x, Solaris 2.x,
> > and Tru64 UNIX 4.x, 5.x.
>
> It should at least retain the original behavior on other platforms.
> And you shou
Albert Chin-A-Young writes:
> > Try changing the code to look like this:
> >
> > if test -L "$file" >/dev/null 2>&1 || test -h "$file" >/dev/null 2>&1 || test
>-f "$file"; then
>
> Well, examine the following:
> $ /bin/sh
> $ test -X "/etc/passwd" || echo foo
> test: argument expected
Eric Lemings <[EMAIL PROTECTED]> writes:
>
> Well I for one was unaware of the PKG_CONFIG_PATH variable. If that is true
> however, how are client packages supposed to know where their .pc files are
> supposed to be installed if this variable can be changed? Right now, I think most
> assume th
Hi Chris,
On Saturday 21 April 2001 10:28 pm, Christoph Pfisterer wrote:
> I ran the test suite on Mac OS X 10.0.1, a.k.a. Darwin 1.3, host type
> powerpc-apple-darwin1.3, with automake 1.4, autoconf 2.13, Apple cc
> (based on gcc 2.95.2), Apple ld (_not_ based on gld).
Thanks!
> It failed 8 of
On Saturday 21 April 2001 9:36 pm, Matthew Schalit wrote:
> Hi Gary, I gave your patch a try and it didn't work correctly in the
> end, which was odd. I looked at configure, and the patch was corrupted.
> The square brackets were missing:
My bad. Since libtool.m4 is processed by m4, one level
On Saturday 21 April 2001 10:02 pm, Matthew Schalit wrote:
> The only other thing I noticed was this section in libltdl/configure:
> ---
> echo "$as_me:7795: checking whether deplibs are loaded by dlopen" >&5
> echo $ECHO_N "c
On Saturday 21 April 2001 11:20 pm, Peter Eisentraut wrote:
> Gary V. Vaughan writes:
> > Failing major disasters, or the discovery of a showstopper, there are
> > less than 18 hours to go before the release of libtool-1.4 from CVS HEAD.
>
> I think that's going to be a problem for you:
>
> libtoo
On Saturday 21 April 2001 11:20 pm, Peter Eisentraut wrote:
>
> I'm not sure whether the compilation error is valid, but this system has
> a pretty pedantic C99 compiler. Here's a patch:
>
> 2001-04-21 Peter Eisentraut <[EMAIL PROTECTED]>
>
> * libltdl/ltdl.c (trim): Don't inline. Unixwa
On Saturday 21 April 2001 6:12 pm, I wrote:
> Failing major disasters, or the discovery of a showstopper, there are less
> than 18 hours to go before the release of libtool-1.4 from CVS HEAD.
I think that the problem several hosts are having with quote.test are a
showstopper -- particularly wit
On Sun, Apr 22, 2001 at 08:05:38PM +0200, Peter Eisentraut wrote:
> Albert Chin-A-Young writes:
>
> > > Try changing the code to look like this:
> > >
> > > if test -L "$file" >/dev/null 2>&1 || test -h "$file" >/dev/null 2>&1 ||
>test -f "$file"; then
> >
> > Well, examine the following:
>
Eric Lemings wrote:
> What I do know though is that a few (if not several) packages are already using
> pkg-config. So if libtool is extended with that functionality, it should be
> compatible with the current behavior of pkg-config. This means that libtool
> would first look for the .pc files
Alexandre Oliva <[EMAIL PROTECTED]> writes:
> On Apr 21, 2001, Havoc Pennington <[EMAIL PROTECTED]> wrote:
>
> > This would also help handle -R on Solaris and stuff like that.
>
> If it could handle a list of packages at once, yes, it would probably
> help on other systems such as DU too. But
[EMAIL PROTECTED] wrote:
> On Sun, Apr 22, 2001 at 01:29:23AM -0600, Eric Lemings wrote:
>
> > I was thinking that if the data maintained by pkg-config could somehow be
> > added to the .la files and libtool could keep track (a registry perhaps) of
> > installed .la files, that would just about c
On Sun, Apr 22, 2001 at 01:29:23AM -0600, Eric Lemings wrote:
> Alexandre Oliva wrote:
> > I could do it with the current scheme, and tweaking PATH
> > is all it takes for me to choose which one a certain package will
> > find. I don't see how you'd accomplish that with a single pkg-config.
>
>
Alexandre Oliva <[EMAIL PROTECTED]> writes:
> On Apr 21, 2001, Eric Lemings <[EMAIL PROTECTED]> wrote:
>
> > 2.0 spawned a separate tool called pkg-config that allows all packages
> > to use one tool rather than several different scripts to query compile
> > flags, link flags, and other configur
The fgrep of .libs in the executable to detect if .libs was hardcoded
is very weak. Methinks a much better approach is to dump the .dynamic
section of the executable and look at RPATH (or equivalent). Patch
below to override the fgrep test for IRIX 6.x, Solaris 2.x, and Tru64
UNIX 4.x, 5.x.
--
a
Alexandre Oliva wrote:
> On Apr 22, 2001, Eric Lemings <[EMAIL PROTECTED]> wrote:
>
> > It works the same more or less. New Autoconf macros that use pkg-config
> > look for it in the current path and it looks for data on installed
> > libraries in its data directory.
>
> And how are packages goi
Havoc Pennington wrote:
I think for libtool it's as simple as having a concept
of a "package"
in addition to a concept of a library, so we can pass "gtk+-2.0" to
libtool instead of "-L/home/hp/unst/lib -L/usr/X11R6/lib -lgtk-x11-1.3
-lgdk-x11-1.3 -lXext -lgdk_pixbuf-1.3 -lm -lpangox -lX11 -lpango
While running 'make check' on the 1.4 branch for Solaris, the *-unst
tests were failing. Does anyone know if 'test -L' is portable? Solaris
/bin/sh doesn't like it:
$ uname -a
SunOS gax 5.8 Generic_108528-02 sun4u sparc SUNW,Ultra-2
$ /bin/sh
$ /usr/bin/test -L /tmp/foo
$ test -L /tmp/fo
On Apr 22, 2001, Eric Lemings <[EMAIL PROTECTED]> wrote:
> It works the same more or less. New Autoconf macros that use pkg-config
> look for it in the current path and it looks for data on installed
> libraries in its data directory.
And how are packages going to register their own data into p
Alexandre Oliva wrote:
> On Apr 21, 2001, Eric Lemings <[EMAIL PROTECTED]> wrote:
>
> > 2.0 spawned a separate tool called pkg-config that allows all packages
> > to use one tool rather than several different scripts to query compile
> > flags, link flags, and other configuration data.
>
> What I
"Gary V. Vaughan" wrote:
>
> Hi everyone,
> $ ./configure
> ...
>
> Configuring libtool 1.3e (1.900 2001/04/20 20:55:18)
>
> ...
> checking host system type... i686-pc-linux-gnu
This is an
On Apr 22, 2001, Eric Lemings <[EMAIL PROTECTED]> wrote:
> Currently, they just install their .pc file into pkg-config's data directory.
Which is exactly the wrong approach. A package should never, ever
install anything outside the --prefix/--exec-prefix/--*dir specified
by the user. Having st
On Apr 22, 2001, Havoc Pennington <[EMAIL PROTECTED]> wrote:
> There's a PKG_CONFIG_PATH that controls where pkg-config looks for the
> data files. So now you don't actually have to do PATH, just
> PKG_CONFIG_PATH.
Phew! Good :-)
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.
On Apr 22, 2001, Havoc Pennington <[EMAIL PROTECTED]> wrote:
> pkg-config has some intelligence, i.e. if you request two libs at once
> it will nuke duplicate flags and order the -l flags properly.
Err... It won't always remove duplicate -l flags, will it? This
isn't always correct.
> Also, i
On Apr 22, 2001, Eric Lemings <[EMAIL PROTECTED]> wrote:
> Exactly. So how would you get the compiler flags into libtool?
You wouldn't. This is totally out of the scope of libtool. Libtool
is about linking with libraries, not compiling source files so that
they can be linked with them. Not t
On Apr 22, 2001, [EMAIL PROTECTED] wrote:
> Patch below to override the fgrep test for IRIX 6.x, Solaris 2.x,
> and Tru64 UNIX 4.x, 5.x.
It should at least retain the original behavior on other platforms.
And you shouldn't assume host == build, which you seem to do by
invoking host-specific prog
On Sun, Apr 22, 2001 at 07:34:42AM -0300, Alexandre Oliva wrote:
> On Apr 22, 2001, Eric Lemings <[EMAIL PROTECTED]> wrote:
>
>> Currently, they just install their .pc file into pkg-config's data directory.
> Which is exactly the wrong approach. A package should never, ever
> install anything ou
Albert Chin-A-Young writes:
> Because of this, the following code snippet in ltmain.in will always
> fail (and thus 'make uninstall' will always fail on Solaris):
> # Don't error if the file doesn't exist and rm -f was used.
> if test -L "$file" >/dev/null 2>&1 || test -f "$file"; then
>
34 matches
Mail list logo
