* Sander Niemeijer wrote on Wed, Aug 24, 2005 at 10:54:53AM CEST:
I would appreciate it if an item could be added to the TODO list for
the new 2.x branch that solves the issue discussed in the following
thread from about a year ago:
http://lists.gnu.org/archive/html/libtool/2004-11/msg00372
Hi Sander,
On 24 Aug 2005, at 09:54, Sander Niemeijer wrote:
I would appreciate it if an item could be added to the TODO list
for the new 2.x branch that solves the issue discussed in the
following thread from about a year ago:
http://lists.gnu.org/archive/html/libtool/2004-11/msg00372
Hi Sander,
* Sander Niemeijer wrote on Wed, Aug 24, 2005 at 10:54:53AM CEST:
> I would appreciate it if an item could be added to the TODO list for
> the new 2.x branch that solves the issue discussed in the following
> thread from about a year ago:
>
> http://lists.gnu.o
I would appreciate it if an item could be added to the TODO list for
the new 2.x branch that solves the issue discussed in the following
thread from about a year ago:
http://lists.gnu.org/archive/html/libtool/2004-11/msg00372.html
Best regards,
Sander Niemeijer
Ralf Wildenhues wrote:
* Gary V. Vaughan wrote on Mon, Aug 22, 2005 at 10:00:50PM CEST:
Is there a public record of these? TODO file? Search string for the
list archives? next mail in this thread? ;-)
The following is not very well ordered, not very well cross-referenced,
has nonempty
* Gary V. Vaughan wrote on Mon, Aug 22, 2005 at 10:00:50PM CEST:
>
> Is there a public record of these? TODO file? Search string for the
> list archives? next mail in this thread? ;-)
The following is not very well ordered, not very well cross-referenced,
has nonempty overlap with th
Gary V. Vaughan wrote:
Do you want me to copy it into CVS TODO?
Sure, you'd probably make a better job of it than me :)
Thanks,
Peter
--
Peter O'Gorman - http://www.pogma.com
___
Libtool mailing list
[EMAIL PROTECTED]
http://lists.gnu.o
Gary V. Vaughan wrote:
Peter O'Gorman wrote:
libtool todo list
> [[snip]]
Rewrite everything in perl, and use xml and xslt just to annoy Gary.
I quit!
But seriously, thanks for working through that convoluted thread!
I owe you a(nother) beer.
Do you want me to copy it into CVS TODO
Peter O'Gorman wrote:
libtool todo list
> [[snip]]
Rewrite everything in perl, and use xml and xslt just to annoy Gary.
I quit!
--
Gary V. Vaughan ())_. [EMAIL PROTECTED],gnu.org}
Research Scientist ( '/ http://tkd.kicks-ass.net
GNU Hacker / )= http://www.gnu
* Peter O'Gorman wrote on Sat, Nov 27, 2004 at 04:14:46PM CET:
>
> Support dlmopen dladdr1 and dlinfo in libltdl [I totally disagree with
> this one Ralf, libltdl is a portability library, none of these functions
> enhance portability in any way]
Just throw this out then! I just mentioned them b
libtool todo list
Sort out the macro mess in libtool.m4. We've started this already
by refactoring chunks into separate files, but I never did completely
untangle the mess of macros imported from ltconfig.
Finish the rewrite of the core libltdl. The loaders are fine, and
the outlying code i
Bob Friesenhahn wrote:
On Wed, 10 Nov 2004, Gary V. Vaughan wrote:
It wouldn't be at all difficult to have 'libtoolize --ltdl
--disable-nls' install a non-internationalised libltdl minus message
catalogues into a parent package. But yes, we would have to take care
to do it carefully. An improv
On Wed, Nov 17, 2004 at 08:58:35AM +0100, Ralf Wildenhues wrote:
> * Jacob Meuser wrote on Wed, Nov 17, 2004 at 01:07:20AM CET:
> > On Tue, Nov 16, 2004 at 11:00:34PM +, Scott James Remnant wrote:
> > > On Tue, 2004-11-16 at 11:15 -0800, Jacob Meuser wrote:
> > > > On Tue, Nov 16, 2004 at 03:02
* Jacob Meuser wrote on Wed, Nov 17, 2004 at 01:07:20AM CET:
> On Tue, Nov 16, 2004 at 11:00:34PM +, Scott James Remnant wrote:
> > On Tue, 2004-11-16 at 11:15 -0800, Jacob Meuser wrote:
> > > On Tue, Nov 16, 2004 at 03:02:55PM +, Scott James Remnant wrote:
> > > > Actually, I'd say the opp
On Tue, Nov 16, 2004 at 11:00:34PM +, Scott James Remnant wrote:
> On Tue, 2004-11-16 at 11:15 -0800, Jacob Meuser wrote:
>
> > On Tue, Nov 16, 2004 at 03:02:55PM +, Scott James Remnant wrote:
> > > Actually, I'd say the opposite is true ... the LONGER link line,
> > > produced by the curr
On Tue, 2004-11-16 at 11:15 -0800, Jacob Meuser wrote:
> On Tue, Nov 16, 2004 at 03:02:55PM +, Scott James Remnant wrote:
> > Actually, I'd say the opposite is true ... the LONGER link line,
> > produced by the current Libtool, is what allows people to get away with
> > this because Libtool pu
On Tue, Nov 16, 2004 at 09:10:00PM +0100, Ralf Wildenhues wrote:
> * Jacob Meuser wrote on Tue, Nov 16, 2004 at 08:00:28PM CET:
> > On Tue, Nov 16, 2004 at 03:01:06PM +, Scott James Remnant wrote:
> > > On Mon, 2004-11-15 at 10:51 -0800, Jacob Meuser wrote:
> > >
> > > > On Mon, Nov 15, 2004 a
* Jacob Meuser wrote on Tue, Nov 16, 2004 at 08:00:28PM CET:
> On Tue, Nov 16, 2004 at 03:01:06PM +, Scott James Remnant wrote:
> > On Mon, 2004-11-15 at 10:51 -0800, Jacob Meuser wrote:
> >
> > > On Mon, Nov 15, 2004 at 03:45:10PM +, Scott James Remnant wrote:
> > > > It does assume that
On Tue, Nov 16, 2004 at 03:02:55PM +, Scott James Remnant wrote:
> On Mon, 2004-11-15 at 17:19 -0600, Bob Friesenhahn wrote:
>
> > On Mon, 15 Nov 2004, Gary V. Vaughan wrote:
> > >> Bob Friesenhahn wrote:
> > >>>
> > >>> Doesn't this patch cause Linux to be more equal than other operating
> >
On Tue, Nov 16, 2004 at 03:01:06PM +, Scott James Remnant wrote:
> On Mon, 2004-11-15 at 10:51 -0800, Jacob Meuser wrote:
>
> > On Mon, Nov 15, 2004 at 03:45:10PM +, Scott James Remnant wrote:
> > > It does assume that all library dependencies are registered, yes. This
> > > has never bee
On Mon, 2004-11-15 at 10:51 -0800, Jacob Meuser wrote:
> On Mon, Nov 15, 2004 at 03:45:10PM +, Scott James Remnant wrote:
> > It does assume that all library dependencies are registered, yes. This
> > has never been a problem, because we've never found any Libtool-produced
> > library that do
On Mon, 2004-11-15 at 17:19 -0600, Bob Friesenhahn wrote:
> On Mon, 15 Nov 2004, Gary V. Vaughan wrote:
> >> Bob Friesenhahn wrote:
> >>>
> >>> Doesn't this patch cause Linux to be more equal than other operating
> >>> systems, thereby causing free applications to be developed which won't
> >>> w
* Gary V. Vaughan wrote on Mon, Nov 15, 2004 at 04:34:49PM CET:
>
> >+2004-03-28 Scott James Remnant <[EMAIL PROTECTED]>
> >+
> >+* ltmain.in: The dynamic link loader on some platforms is able to
> >+correctly traverse dependency trees, therefore when $link_all_deplibs
> >+is set to
* Howard Chu wrote on Mon, Nov 15, 2004 at 10:29:04PM CET:
> Ralf Wildenhues wrote:
> >* Gary V. Vaughan wrote on Mon, Nov 15, 2004 at 04:34:49PM CET:
>
> >>Also, what do we do about -rpath? We still need to encode the
> >>runtime path to even the dropped deplib directories so that the
> >>same l
On Tue, Nov 16, 2004 at 12:00:09AM -0500, Daniel Reed wrote:
> On 2004-11-15T20:33-0800, Jacob Meuser wrote:
> ) their packages as soon as possible. besides, it is arguable that
> ) libtool should be fairly well adapted to RedHat by default, the
> ) 1.5 branch has been around for a while now, and
On 2004-11-15T20:33-0800, Jacob Meuser wrote:
) their packages as soon as possible. besides, it is arguable that
) libtool should be fairly well adapted to RedHat by default, the
) 1.5 branch has been around for a while now, and you are still
) shipping patches?
Until 1.5.10, we were actually pat
On Mon, Nov 15, 2004 at 07:36:21PM -0500, Daniel Reed wrote:
> On 2004-11-15T17:19-0600, Bob Friesenhahn wrote:
> ) system incrementally. There is also the point that the libtool which
> ) comes with a Linux distribution has likely already been hacked to be
> ) more lenient. If FSF libtool become
On Mon, Nov 15, 2004 at 08:01:38PM -0600, Bob Friesenhahn wrote:
> On Mon, 15 Nov 2004, Jacob Meuser wrote:
> >
> >but this only works is all the libraries have .la files, right?
> >what happens if not all those libraries were built with libtool?
> >how would libtool find the dependent libraries if
On 2004-11-15T19:27-0600, Bob Friesenhahn wrote:
) >> Yes. When you're making a distribution, Libtool's behaviour of directly
) >> linking indirect-dependencies is insane. For a SONAME change to a
) >> library deep in the stack, that only affects the library immediately
) >> above it, you suddenl
On Mon, 15 Nov 2004, Jacob Meuser wrote:
but this only works is all the libraries have .la files, right?
what happens if not all those libraries were built with libtool?
how would libtool find the dependent libraries if there is no .la?
That is a function of pkg-config. :-)
From the outside, nothin
On Tue, Nov 16, 2004 at 01:20:58AM +, Gary V. Vaughan wrote:
> Bob Friesenhahn wrote:
> >On Mon, 15 Nov 2004, Gary V. Vaughan wrote:
> >
> >>>Bob Friesenhahn wrote:
> >>>
>
> Doesn't this patch cause Linux to be more equal than other operating
> systems, thereby causing free applic
On Tue, 16 Nov 2004, Gary V. Vaughan wrote:
under Linux, but the authors expect them to be portable because they use
autotools and standard APIs. It seems that the shortened link line will
allow developers to not list the dependencies which are necessary on some
other platforms.
That's not what
On Mon, 15 Nov 2004, Joe Orton wrote:
Yes. When you're making a distribution, Libtool's behaviour of directly
linking indirect-dependencies is insane. For a SONAME change to a
library deep in the stack, that only affects the library immediately
above it, you suddenly need to rebuild your entire
Bob Friesenhahn wrote:
On Mon, 15 Nov 2004, Gary V. Vaughan wrote:
Bob Friesenhahn wrote:
Doesn't this patch cause Linux to be more equal than other operating
systems, thereby causing free applications to be developed which won't
work anywhere else?
No, it just shortens the link line on platforms
On 2004-11-15T17:19-0600, Bob Friesenhahn wrote:
) system incrementally. There is also the point that the libtool which
) comes with a Linux distribution has likely already been hacked to be
) more lenient. If FSF libtool becomes more lenient by default, then
) there likely little actual impact.
On Mon, 15 Nov 2004, Gary V. Vaughan wrote:
Bob Friesenhahn wrote:
Doesn't this patch cause Linux to be more equal than other operating
systems, thereby causing free applications to be developed which won't
work anywhere else?
No, it just shortens the link line on platforms that support that.
The p
> At first I thought that would be to absorb pkg-config's
> functionality into libtool (to avoid duplication of code and
> maintenance),
Just in case somebody still ponders this, please take into account
that pkg-config works even for people on Windows who use MSVC (the
command-line tools, not
Ralf Wildenhues wrote:
* Gary V. Vaughan wrote on Mon, Nov 15, 2004 at 04:34:49PM CET:
Also, what do we do about -rpath? We still need to encode the
runtime path to even the dropped deplib directories so that the
same library we linked with is picked up at runtime.
Erm, is this not handled in th
s a good idea, if we know the linker can find deplibs without
help, we should take advantage of that to shorten the link line!
Please add it to TODO.
Seconded (or thirded, or whoever also wants this).
On systems where deplibs are handled by the linker,
libtool should give the advantage back to the
On Mon, Nov 15, 2004 at 03:45:10PM +, Scott James Remnant wrote:
> On Mon, 2004-11-15 at 15:34 +, Gary V. Vaughan wrote:
>
> > Scott James Remnant wrote:
> >
> > > I submitted keybuk-linux-deplibs.patch to libtool-patches back in March,
> > > and there was a slight objection from Bob and
* Gary V. Vaughan wrote on Mon, Nov 15, 2004 at 04:34:49PM CET:
> >Bob Friesenhahn wrote:
> >>
> >>This solution does not seem to support the case where an actual
> >>dependency exists but is not registered in the library (because the
> >>user didn't supply it) so that the dynamic link loader doesn
On Mon, 2004-11-15 at 15:51 +, Joe Orton wrote:
> On Mon, Nov 15, 2004 at 02:42:51PM +, Scott James Remnant wrote:
> > On Mon, 2004-11-15 at 13:16 +, Gary V. Vaughan wrote:
> >
> > > Ralf Wildenhues wrote:
> > > Scott James Remnant wrote:
> > > >
> > > >They're both trying
On Mon, 2004-11-15 at 15:34 +, Gary V. Vaughan wrote:
> Scott James Remnant wrote:
>
> > I submitted keybuk-linux-deplibs.patch to libtool-patches back in March,
> > and there was a slight objection from Bob and nobody else joined in to
> > ok it.
>
> The list was very busy around then, and
On Mon, Nov 15, 2004 at 02:42:51PM +, Scott James Remnant wrote:
> On Mon, 2004-11-15 at 13:16 +, Gary V. Vaughan wrote:
>
> > Ralf Wildenhues wrote:
> > Scott James Remnant wrote:
> > >
> > >They're both trying to deal with platforms like Solaris that don't have
> > >a nee
Scott James Remnant wrote:
I submitted keybuk-linux-deplibs.patch to libtool-patches back in March,
and there was a slight objection from Bob and nobody else joined in to
ok it.
The list was very busy around then, and I was waiting to see the results
of you and Bob duking it out ;-) You didn't ans
* Peter O'Gorman wrote on Tue, Nov 09, 2004 at 02:46:09PM CET:
> I just want to get some possibilities out there into the ether. Feel free
> to add more bits/say which bits are silly.
>
> Post 2.0:
glibc HEAD NEWS has:
|
| Namespaces in ld.so are implemented. DSOs can be loaded in separate
| na
On Mon, 2004-11-15 at 13:16 +, Gary V. Vaughan wrote:
> Ralf Wildenhues wrote:
> Scott James Remnant wrote:
> >
> >They're both trying to deal with platforms like Solaris that don't have
> >a needed-following link loader.
>
> > The patch that is in Debian's libtool?
>
> It is
On Sun, 2004-11-14 at 14:45 -0600, Bob Friesenhahn wrote:
> On Sun, 14 Nov 2004, Albert Chin wrote:
>
> > On Sun, Nov 14, 2004 at 08:57:27AM +, Scott James Remnant wrote:
> >> They're both trying to deal with platforms like Solaris that don't have
> >> a needed-following link loader.
> >
> >
On Sun, 2004-11-14 at 17:37 -0800, Jacob Meuser wrote:
> On Sun, Nov 14, 2004 at 08:53:15AM +, Scott James Remnant wrote:
> > I actually tend to think we should look at this the other way ... if we
> > could expose the information Libtool has to other tools, pkg-config
> > could defer to Libto
On Sun, 2004-11-14 at 13:35 -0500, Daniel Reed wrote:
> On 2004-11-14T08:50-, Scott James Remnant wrote:
> ) On Fri, 2004-11-12 at 11:20 +, Gary V. Vaughan wrote:
> ) > Haven't thought through the -I thing yet though... maybe that doesn't
> ) > belong in libtool... maybe we could provide a
Ralf Wildenhues wrote:
Scott James Remnant wrote:
They're both trying to deal with platforms like Solaris that don't have
a needed-following link loader.
So will libtool do The Right Thing in all circumstances, given
the tiny patch to enable link_all_deps=yes on linux and whatever
other system has
that don't have
> >>>a needed-following link loader.
> >>
> >>That's a good idea, if we know the linker can find deplibs without
> >>help, we should take advantage of that to shorten the link line!
> >>Please add it to TODO.
> >
Hi Howard!
Howard Chu wrote:
That's great for shared libraries, but one of the things I actually like
about libtool is the automatic dependency inclusion when linking static
libraries. I.e., plain 'ol .a archives are much less friendlier without
libtool because they don't carry any dependency in
know the linker can find deplibs without
help, we should take advantage of that to shorten the link line!
Please add it to TODO.
Seconded (or thirded, or whoever also wants this).
On systems where deplibs are handled by the linker,
libtool should give the advantage back to the user.
IMVHO this is
know the linker can find deplibs without
help, we should take advantage of that to shorten the link line!
Please add it to TODO.
Seconded (or thirded, or whoever also wants this).
On systems where deplibs are handled by the linker,
libtool should give the advantage back to the user.
IMVHO this is
Hi Jacob,
Jacob Meuser wrote:
On Sun, Nov 14, 2004 at 09:04:31PM +, Gary V. Vaughan wrote:
Hi Bob!
Bob Friesenhahn wrote:
You seem to be a victim of a package install where every package has
used its own unique installation prefix. It seems to me that most
systems use just one or two install
a good idea, if we know the linker can find deplibs without
> help, we should take advantage of that to shorten the link line!
> Please add it to TODO.
Seconded (or thirded, or whoever also wants this).
On systems where deplibs are handled by the linker,
libtool should give the advantage back
On Sun, Nov 14, 2004 at 09:04:31PM +, Gary V. Vaughan wrote:
> Hi Bob!
>
> Bob Friesenhahn wrote:
> >You seem to be a victim of a package install where every package has
> >used its own unique installation prefix. It seems to me that most
> >systems use just one or two installation prefixes
Hi Jacob,
Jacob Meuser wrote:
On Sun, Nov 14, 2004 at 05:09:08PM -0500, Daniel Reed wrote:
On 2004-11-14T14:56-0600, Bob Friesenhahn wrote:
) On Sun, 14 Nov 2004, Gary V. Vaughan wrote:
) > $ PKG_CONFIG_PATH=/opt/libgdiplus10/lib/pkgconfig
) You seem to be a victim of a package install where every
On Sun, Nov 14, 2004 at 08:53:15AM +, Scott James Remnant wrote:
> On Fri, 2004-11-12 at 23:02 -0800, Jacob Meuser wrote:
>
> > > It doesn't care about package versions, but it has to care about library
> > > versions and paths to libraries.
> >
> > again, functionality provided by pkg-config
On Sun, Nov 14, 2004 at 05:09:08PM -0500, Daniel Reed wrote:
> On 2004-11-14T14:56-0600, Bob Friesenhahn wrote:
> ) On Sun, 14 Nov 2004, Gary V. Vaughan wrote:
> ) > $ PKG_CONFIG_PATH=/opt/libgdiplus10/lib/pkgconfig
> ) You seem to be a victim of a package install where every package has
> ) used i
On 2004-11-14T14:56-0600, Bob Friesenhahn wrote:
) On Sun, 14 Nov 2004, Gary V. Vaughan wrote:
) > $ PKG_CONFIG_PATH=/opt/libgdiplus10/lib/pkgconfig
) You seem to be a victim of a package install where every package has
) used its own unique installation prefix. It seems to me that most
) systems
On Sun, 14 Nov 2004, Gary V. Vaughan wrote:
Hi Bob!
Bob Friesenhahn wrote:
You seem to be a victim of a package install where every package has used
its own unique installation prefix. It seems to me that most systems use
just one or two installation prefixes.
Absolutely.
But the point is that p
On Sun, Nov 14, 2004 at 08:53:15AM +, Scott James Remnant wrote:
> On Fri, 2004-11-12 at 23:02 -0800, Jacob Meuser wrote:
>
> > > It doesn't care about package versions, but it has to care about library
> > > versions and paths to libraries.
> >
> > again, functionality provided by pkg-config
On Sun, Nov 14, 2004 at 08:57:27AM +, Scott James Remnant wrote:
> On Sat, 2004-11-13 at 15:27 -0800, Jacob Meuser wrote:
>
> > On Sat, Nov 13, 2004 at 10:21:19AM +0100, Ralf Corsepius wrote:
> > > It's just that their functionality
> > > intersects and partially conflicts.
> >
> > how?
> >
On Sun, Nov 14, 2004 at 09:04:31PM +, Gary V. Vaughan wrote:
> You mean that the installed .pc files need to be altered by the
> user to give things a hope of linking? ;-)
Hate to chime in, but I always seem to have to add -Wl,-R... to the *.pc
files, so have not ended up being a fan of pkg-co
Hi Bob!
Bob Friesenhahn wrote:
You seem to be a victim of a package install where every package has
used its own unique installation prefix. It seems to me that most
systems use just one or two installation prefixes.
Absolutely.
But the point is that pkg-config is supposed to help with parallel
On Sun, 14 Nov 2004, Gary V. Vaughan wrote:
My main complaint about pkg-config is this: It is supposed to
make it easier to link with packages that have each been installed
to their own prefix (to support parallel installation of multiple
versions), but in fact it makes things much harder.
Real wo
On Sun, 14 Nov 2004, Albert Chin wrote:
On Sun, Nov 14, 2004 at 08:57:27AM +, Scott James Remnant wrote:
They're both trying to deal with platforms like Solaris that don't have
a needed-following link loader.
What does this mean?
I assume that he is talking about ELF inherited dependencies. Wit
-Wl,/opt/libungif41/lib \
-Wl,-rpath -Wl,/opt/libpng12/lib \
-Wl,-rpath -Wl,/opt/zlib11/lib
And *that* is why I think pkg-config is an aberration.
They're both trying to deal with platforms like Solaris that don't have
a needed-following link loader.
That's a good idea, if we know the l
On Sun, Nov 14, 2004 at 08:57:27AM +, Scott James Remnant wrote:
> They're both trying to deal with platforms like Solaris that don't have
> a needed-following link loader.
What does this mean?
--
albert chin ([EMAIL PROTECTED])
___
Libtool maili
On 2004-11-14T08:50-, Scott James Remnant wrote:
) On Fri, 2004-11-12 at 11:20 +, Gary V. Vaughan wrote:
) > Haven't thought through the -I thing yet though... maybe that doesn't
) > belong in libtool... maybe we could provide a macro that can intuit
) > include directories from .la locatio
On Fri, 2004-11-12 at 23:02 -0800, Jacob Meuser wrote:
> > It doesn't care about package versions, but it has to care about library
> > versions and paths to libraries.
>
> again, functionality provided by pkg-config.
>
> I am contesting the claim "Libtool already has all the information
> it ne
On Sat, 2004-11-13 at 15:27 -0800, Jacob Meuser wrote:
> On Sat, Nov 13, 2004 at 10:21:19AM +0100, Ralf Corsepius wrote:
> > It's just that their functionality
> > intersects and partially conflicts.
>
> how?
>
> pkg-config is used to give basic information about installed packages.
> libtool is
On Fri, 2004-11-12 at 11:20 +, Gary V. Vaughan wrote:
> Albert Chin wrote:
> > On Wed, Nov 10, 2004 at 03:43:48PM +, Scott James Remnant wrote:
> >
> > Ick. Libtool is about portably building/using libraries. Why can't we
> > leave it at that?
>
> But linking against installed libraries
On Sat, 13 Nov 2004, Jacob Meuser wrote:
libtool is used to build libraries.
pkg-config is used in configure scripts.
libtool is used in Makefiles.
yes, it's possible to use constructs like
foo.so: foo.o
${CC} ${LDFLAGS} -o foo.so foo.o `pkg-config bar --libs`
in Makefiles, but this is not
On Sat, Nov 13, 2004 at 10:21:19AM +0100, Ralf Corsepius wrote:
> On Fri, 2004-11-12 at 23:02 -0800, Jacob Meuser wrote:
> > On Sat, Nov 13, 2004 at 04:27:28AM +0100, Ralf Corsepius wrote:
> > > On Fri, 2004-11-12 at 14:31 -0800, Jacob Meuser wrote:
> > > > On Fri, Nov 12, 2004 at 03:33:02PM -0600,
On Sat, 13 Nov 2004, Ralf Corsepius wrote:
Well, current libtool does not support multilibs.
If multilibs should ever be able to support them, I'd expect libtool
having to examine the whole command being used, comprising CFLAGS and
CPPFLAGS (There exist targets where multilib variants are being
tri
On Fri, 2004-11-12 at 23:02 -0800, Jacob Meuser wrote:
> On Sat, Nov 13, 2004 at 04:27:28AM +0100, Ralf Corsepius wrote:
> > On Fri, 2004-11-12 at 14:31 -0800, Jacob Meuser wrote:
> > > On Fri, Nov 12, 2004 at 03:33:02PM -0600, Albert Chin wrote:
> > > > On Fri, Nov 12, 2004 at 11:20:13AM +, Ga
On Sat, Nov 13, 2004 at 04:27:28AM +0100, Ralf Corsepius wrote:
> On Fri, 2004-11-12 at 14:31 -0800, Jacob Meuser wrote:
> > On Fri, Nov 12, 2004 at 03:33:02PM -0600, Albert Chin wrote:
> > > On Fri, Nov 12, 2004 at 11:20:13AM +, Gary V. Vaughan wrote:
> > > > Albert Chin wrote:
> > > > > On We
On Fri, 2004-11-12 at 14:31 -0800, Jacob Meuser wrote:
> On Fri, Nov 12, 2004 at 03:33:02PM -0600, Albert Chin wrote:
> > On Fri, Nov 12, 2004 at 11:20:13AM +, Gary V. Vaughan wrote:
> > > Albert Chin wrote:
> > > > On Wed, Nov 10, 2004 at 03:43:48PM +, Scott James Remnant wrote:
> > > >
>
On Fri, Nov 12, 2004 at 03:33:02PM -0600, Albert Chin wrote:
> On Fri, Nov 12, 2004 at 11:20:13AM +, Gary V. Vaughan wrote:
> > Albert Chin wrote:
> > > On Wed, Nov 10, 2004 at 03:43:48PM +, Scott James Remnant wrote:
> > >
> > >>On Tue, 2004-11-09 at 14:24 +, Gary V. Vaughan wrote:
>
On Fri, 12 Nov 2004, Albert Chin wrote:
There's actually a couple of things pkg-config does that Libtool doesn't
currently do. pkg-config's main job can be summed up simply as enabling
parallel-installed -dev packages.
What about non-libtool libraries wanting to benefit from pkg-config?
This will
On Fri, Nov 12, 2004 at 11:20:13AM +, Gary V. Vaughan wrote:
> Albert Chin wrote:
> > On Wed, Nov 10, 2004 at 03:43:48PM +, Scott James Remnant wrote:
> >
> >>On Tue, 2004-11-09 at 14:24 +, Gary V. Vaughan wrote:
> >>
> >>
> >>>6. Absorb the functionality of the aberration called pkg-
Hi Albert!
Albert Chin wrote:
> On Wed, Nov 10, 2004 at 03:43:48PM +, Scott James Remnant wrote:
>
>>On Tue, 2004-11-09 at 14:24 +, Gary V. Vaughan wrote:
>>
>>
>>>6. Absorb the functionality of the aberration called pkg-config. Libtool
>>>already has all the information it needs, w
On Wed, Nov 10, 2004 at 03:43:48PM +, Scott James Remnant wrote:
> On Tue, 2004-11-09 at 14:24 +, Gary V. Vaughan wrote:
>
> > 6. Absorb the functionality of the aberration called pkg-config. Libtool
> > already has all the information it needs, we just need to teach it (or
> > m
On Wed, Nov 10, 2004 at 10:44:33PM +0100, Alexandre Duret-Lutz wrote:
> Strictly speaking automake does not know these dependencies. It
> knows some dependencies, but because of the possibility to
> AC_SUBST variables for conditional linking, and doest not know
> exactly all of them (think libfoo_
On Wed, 2004-11-10 at 12:17 -0600, Bob Friesenhahn wrote:
> On Wed, 10 Nov 2004, Ralf Wildenhues wrote:
>
> >> However it *also* provides the right -I flags to point at the include
> >> files. A GTK+ application will '#include ' for example
> >> and require -I/usr/include/gtk-2.0 to actually be
>>> "Noah" == Noah Misch <[EMAIL PROTECTED]> writes:
Noah> On Wed, Nov 10, 2004 at 01:17:19AM +0100, Alexandre Duret-Lutz wrote:
>> - the relinking dependency debacle:
>>
>> For libtool to relink libraries when installing them, all
>> dependencies must have been installed. However automake
On Wed, 10 Nov 2004, Noah Misch wrote:
A problem exists in that if a library is already installed on
the system, it may be used by accident, either at build time, or at
install time. This masks serious build/install ordering issues.
Yes.
Automake could unmask these issues by unlinking every file
On Wed, Nov 10, 2004 at 08:52:00PM +0100, Ralf Wildenhues wrote:
> * Bob Friesenhahn wrote on Wed, Nov 10, 2004 at 08:31:15PM CET:
> > On Wed, 10 Nov 2004, Noah Misch wrote:
> > >If Automake descends into SUBDIRS to install in the same order it
> > >does to build and uses `make' dependencies to e
[ slightly reformatted ]
* Bob Friesenhahn wrote on Wed, Nov 10, 2004 at 08:31:15PM CET:
> On Wed, 10 Nov 2004, Noah Misch wrote:
> >On Wed, Nov 10, 2004 at 12:28:24PM -0600, Bob Friesenhahn wrote:
> >>The problem is that Automake does *not* know the dependency graph of
> >>each object. Within on
On Wed, 10 Nov 2004, Noah Misch wrote:
On Wed, Nov 10, 2004 at 12:28:24PM -0600, Bob Friesenhahn wrote:
The problem is that Automake does *not* know the dependency graph of
each object. Within one Makefile, this is possible (and mostly
supported) but most projects depend on SUBDIRS to recurse thou
On Wed, Nov 10, 2004 at 12:28:24PM -0600, Bob Friesenhahn wrote:
> The problem is that Automake does *not* know the dependency graph of
> each object. Within one Makefile, this is possible (and mostly
> supported) but most projects depend on SUBDIRS to recurse though
> subordinate Makefiles so
On Wed, 10 Nov 2004, Gary V. Vaughan wrote:
It wouldn't be at all difficult to have 'libtoolize --ltdl --disable-nls'
install a non-internationalised libltdl minus message catalogues into a
parent package. But yes, we would have to take care to do it carefully. An
improved post-2.0 testsuite s
Daniel Reed wrote:
On 2004-11-09T18:19-, Gary V. Vaughan wrote:
) Ralf Wildenhues wrote:
) > * Gary V. Vaughan wrote on Tue, Nov 09, 2004 at 03:24:25PM CET:
) >>3.5. While we are there, maybe internationalise libltdl?
) > Please don't. If you do, make it possible to have zero(!) overhead for
On 2004-11-09T18:19-, Gary V. Vaughan wrote:
) Ralf Wildenhues wrote:
) > * Gary V. Vaughan wrote on Tue, Nov 09, 2004 at 03:24:25PM CET:
) >>3.5. While we are there, maybe internationalise libltdl?
) > Please don't. If you do, make it possible to have zero(!) overhead for
) > ltdl users if t
On Wed, 10 Nov 2004, Noah Misch wrote:
On Wed, Nov 10, 2004 at 01:17:19AM +0100, Alexandre Duret-Lutz wrote:
- the relinking dependency debacle:
For libtool to relink libraries when installing them, all
dependencies must have been installed. However automake cannot
pre-compute this installation
On Wed, 10 Nov 2004, Ralf Wildenhues wrote:
However it *also* provides the right -I flags to point at the include
files. A GTK+ application will '#include ' for example
and require -I/usr/include/gtk-2.0 to actually be able to find that (or
-1.0, -3.0, etc.)
That's a good feature. Dunno whether I
On Wed, Nov 10, 2004 at 01:17:19AM +0100, Alexandre Duret-Lutz wrote:
> - the relinking dependency debacle:
>
> For libtool to relink libraries when installing them, all
> dependencies must have been installed. However automake cannot
> pre-compute this installation order when it is run, and
>
1 - 100 of 139 matches
Mail list logo
