ven, and add the argument when given.
Assuming both maintainer groups are ok with this, I'm happy to cook up
some patches. I'm also happy to hear alternate suggestions?
Scott
--
Scott James Remnant
[EMAIL PROTECTED]
signature.asc
Description: This
the best approach to porting these would be?
Scott
--
Scott James Remnant
[EMAIL PROTECTED]
signature.asc
Description: This is a digitally signed message part
___
http://lists.gnu.org/mailman/listinfo/libtool
On Tue, 2008-09-23 at 14:11 +0200, Ralf Wildenhues wrote:
> * Scott James Remnant wrote on Tue, Sep 23, 2008 at 02:08:03PM CEST:
> > While porting a bunch of GNOME applications from using libtool 1.5 to
> > 2.2, we've encountered a couple that use libtool in their conf
; -o "$flag" = "--start-group" ; then
+ deplibs="$deplibs --start-group"
+ continue;
+ fi
+ if test "$flag" = "-)" -o "$flag" = "--end-group" ; then
+ deplibs="$deplibs --end-group&quo
alternatives (foo.so etc) are not
in the module search path. */
- if (handle || ((errors > 0) && file_not_found ()))
+ if (handle || ((errors > 0) && !file_not_found ()))
{
LT_DLFREE (tmp);
return handle;
--lrZ03NoBR/3+SXJZ--
>8&
On Sun, 2002-12-15 at 17:10, Albert Chin wrote:
> On Sun, Dec 15, 2002 at 04:45:27PM +0000, Scott James Remnant wrote:
> > This is actually two "problems" he's fixing, the first of which
> > definitely looks like a good fix -- the second of which (the third hunk
/libtool --mode=relink powerpc-linux-gcc -Wall -O2 -pipe -g3 -ggdb -o
|libtuxbox-ucodes.la -rpath /usr/lib libucodes.lo ../libmd5sum/libtuxbox-md5sum.la
|@inst_prefix_dir@)"
bastian
--
Another Armenia, Belgium ... the weak innocents who always seem to be
located on a natural invasion route.
On Sun, 2002-12-15 at 17:09, Albert Chin wrote:
> On Sun, Dec 15, 2002 at 04:42:42PM +0000, Scott James Remnant wrote:
> > Certain applications require the linker flags --start-group
> > and --end-group (abbreviated "-(" and "-)" ) in order to
> > reso
On Sun, 2003-07-06 at 11:18, Dalibor Topic wrote:
> Thanks, for an outsider like me, it's hard to understand a project's
> internal social structure. I've got one more question, though: how do
> you handle external patches from distributors? Do you hunt down their
> patches trying to integrate
On Mon, 2003-07-07 at 02:40, Charles Wilson wrote:
> Scott James Remnant wrote:
> > On Sun, 2003-07-06 at 11:18, Dalibor Topic wrote:
>
>
>>http://ftp.debian.org/debian/pool/main/libt/libtool/libtool_1.4.3-10.diff.gz
> >>etc.
> >>
> >
> > As
Subject line says is all really, I ask because I've cleaned up the
Debian libtool 1.4 package and got a small handful of patches which
could be useful if anyone forsees a libtool 1.4.4 coming up at any point
in the future.
If not no worries, a couple of these patches need to be applied to 1.5
too
The libtool documentation, as contained in libtool.info, is currently
licensed under the GNU Free Documentation License (GFDL).
As you are probably aware, there is significant opinion that this
licence does not meet the requirements of the Debian Free Software
Guidelines (DFSG).
This means that t
On Thu, 2003-08-28 at 00:49, Stephen Torri wrote:
> On Wed, 2003-08-27 at 01:50, Schleicher Ralph (LLI) wrote:
> >
> ! If the @samp{-static} option is given, then only a @samp{.o} file is
> ! built, even if libtool was configured with @samp{--disable-static}.
>
> This sounds logically confusing.
(Removed debian lists from Cc, I don't see how this is relevant to the
porters)
On Sat, 2003-09-27 at 06:06, Robert Millan wrote:
> On Sat, Sep 27, 2003 at 02:36:13AM +0100, Scott James Remnant wrote:
> > Use the Debian libtool package, not only do I currently track CVS rather
&g
On Sat, 2003-09-27 at 19:46, Robert Millan wrote:
> On Sat, Sep 27, 2003 at 04:30:15AM +0100, Scott James Remnant wrote:
> > On Sat, 2003-09-27 at 06:06, Robert Millan wrote:
> > > It's not the Debian libtool package which is (generaly) used by upstream
> > > main
On Sat, 2003-09-27 at 21:46, Robert Millan wrote:
> On Sat, Sep 27, 2003 at 07:26:20PM +0100, Scott James Remnant wrote:
> > Updating to any later version of Libtool is the same amount of work,
> > whether it be the Debian-patched version or not. Most of the time, when
> >
On Fri, 2003-09-26 at 20:46, Robert Millan wrote:
> The libtool upstream maintainers are preparing a new 1.5b release. On their
> behalf I've recently attempted to test a snapshot from CVS branch-1-5 on all
> architectures Debian supports (or pretends to support) that I had access to.
>
Actually
On Tue, 2003-09-30 at 09:31, Bernd Jendrissek wrote:
> On Tue, Sep 30, 2003 at 09:33:29AM +0200, Alexandre Duret-Lutz wrote:
> > etc. Keeping odd version for development ensure people cannot
> > mis-sort versions with letters with others. It could also gives
> > some feeling of sense to accustome
On Tue, 2003-09-30 at 10:15, Gary V. Vaughan wrote:
> Alexandre Duret-Lutz wrote:
> > I didn't understand your proposal, but I hope you are not
> > planning to make 2.2 < 2.3a < 2.3. That would be counter
> > intuitive. IMHO any numbering scheme ought to work with `ls -v'.
>
> Actually, that is
On Tue, 2003-09-30 at 17:58, Gary V. Vaughan wrote:
> After the next cron web update, please read:
>
> http://www.gnu.org/software/libtool/contribute.html
>
> and give me your feedback...
>
Makes sense to me, seems to cover everything well enough to avoid any
confusion about what kind of re
Forwarded for discussion purposes ...
I can see Sam's point, but I can also see the reason for suppressing one
of two near-identical compilations.
Scott
-Forwarded Message-
From: Sam Hocevar <[EMAIL PROTECTED]>
To: Debian Bug Tracking System <[EMAIL PROTECTED]>
Subject: Bug#207475: libto
On Tue, 2003-10-07 at 18:48, Robert Millan wrote:
> On Tue, Oct 07, 2003 at 04:36:47PM +0100, Gary V. Vaughan wrote:
> > >>>libtool maintainers: Would you consider giving either Scott or me
> > >>>(preferably
> > >>>both) with CVS access? That'd help a lot getting libtool in shape for all
> > >>>
On Tue, 2003-10-07 at 16:14, Gary V. Vaughan wrote:
> Scott James Remnant wrote:
> > I can see Sam's point, but I can also see the reason for suppressing one
> > of two near-identical compilations.
>
> How about a -no-suppress option? (see attachment)
>
Certainly se
On Tue, 2003-10-07 at 16:36, Gary V. Vaughan wrote:
> Robert Millan wrote:
> > On Sat, Sep 27, 2003 at 08:04:55PM +0100, Scott James Remnant wrote:
> >>Robert Millan wrote:
> >>>We should start doing that, and I can help. Just requested copyright papers
> >&g
On Wed, 2003-11-12 at 20:49, Albert Chin wrote:
> On Wed, Nov 12, 2003 at 06:59:44PM +0100, Paolo Bonzini wrote:
> > I have just upgraded to libtool 1.5 (Debian's package which is taken
> > out of CVS) and here are my first experiences.
>
> HEAD or branch-1-5? I think development is happening on
On Sat, 2003-11-22 at 16:41, Bob Friesenhahn wrote:
> I am trying to get the current CVS libtool properly bootstrapped. The
> libtool bootstrap script says that GNU autoconf 2.58 and GNU automake
> 1.8 are required. There is no such thing as automake 1.8 yet. I
> retrieved a package called autom
On Mon, 2003-11-24 at 17:36, Bob Friesenhahn wrote:
> On Mon, 24 Nov 2003, Scott James Remnant wrote:
> > >
> > I use Autoconf 2.58 and Automake 1.7 (latest Debian packages, basically)
> > to bootstrap and it works just fine.
>
> The top of libtool's
On Tue, 2003-11-25 at 13:24, Gary V. Vaughan wrote:
You've just woken up, haven't you? :-)
> Scott James Remnant wrote:
> | On Mon, 2003-11-24 at 17:36, Bob Friesenhahn wrote:
> |
> |
> |>On Mon, 24 Nov 2003, Scott James Remnant wrote:
> |>
> |>>I
On Tue, 2003-11-25 at 13:27, Gary V. Vaughan wrote:
> Scott James Remnant wrote:
> | The gotcha is that for some reason aclocal pulls in both m4/libtool.m4
> | AND /usr/share/aclocal/libtool.m4 into aclocal.m4 and puts the latter
> | last, so its macros get used.
>
> This mean
On Wed, 2003-11-26 at 11:41, Gary V. Vaughan wrote:
> Scott James Remnant wrote:
> | This means if you use AC_FOO in m4/libtool.m4 then the first file that
> | happens to AC_DEFUN that will get included, even though it's defined
> | with m4_define in that same file.
>
> G
On Wed, 2003-11-26 at 14:51, Thien-Thi Nguyen wrote:
> i recently swiched to libtool 1.5 and now AC_PROG_LIBTOOL pulls in a
> horrendous amount of irrelevant checks for C++ and Fortran. *snip* are
> there plans to extend AC_PROG_LIBTOOL to specify which, if any, tags
> are to be included/omitted?
round the twist?
diff -ruNp libtool-CVS~/ChangeLog libtool-CVS/ChangeLog
--- libtool-CVS~/ChangeLog 2003-11-30 17:13:29.00000 +0000
+++ libtool-CVS/ChangeLog 2003-12-07 18:59:19.0 +
@@ -0,0 +1,7 @@
+2003-12-07 Scott James Remnant <[EMAIL PROTECTED]>
+
+ * ltmain.in:
On Wed, 2003-12-17 at 17:23, Gary V. Vaughan wrote:
> Argh. I am beginning to resent the amount of admin I am doing in what would
> otherwise be my hacking time :-(
>
> It's difficult, tedious and error prone.
>
By using my own subversion mirror which spanned the compromise, I've
been able to m
On Sun, 2003-12-07 at 23:18, Peter O'Gorman wrote:
> Scott James Remnant wrote:
>
> | On Sat, 2003-12-06 at 15:14, Peter O'Gorman wrote:
> |>Looks like it is simply infering too early in link mode.
> |>
> |
> | Yeah, my last patch moved the code to before th
The script and everything under CVSROOT that logged our commits and sent
them to [EMAIL PROTECTED] has been lost.
Don't suppose anyone kept a copy of this around, and could re-add it to
CVSROOT (possibly fixing the broken CVSweb URLs along the way).
Otherwise I guess we'd have to use the commit_p
On Fri, 2004-01-02 at 00:30, Bob Friesenhahn wrote:
> On Fri, 2 Jan 2004, Joe Orton wrote:
>
> > > _ACEOF
> > > cat foo.out
> > >
> > > Note that the update adds an extra backslash in front of all the inner
> > > double-quotes.
> >
> > OK, I made those changes to libtool.m4 as below, and can conf
On Thu, 2003-12-18 at 12:08, Peter O'Gorman wrote:
> Gary V. Vaughan wrote:
> | Scott James Remnant wrote:
> | We're done!
>
> Jeez, I didn't even get the chance to start looking!
>
> Thank you both so much, I'll buy both multiple beers should we ever
On Wed, 2003-11-26 at 15:49, Gary V. Vaughan wrote:
> Scott James Remnant wrote:
> |On Wed, 2003-11-26 at 11:41, Gary V. Vaughan wrote:
> |> 1: remove $prefix/share/aclocal/l(ibtoo|td)l.m4 of old releases at install
> |> time
> |> 2: keep copies of the latest versio
Bootstrapping the new stuff with Automake 1.8 and an older
/usr/share/aclocal/libtool.m4 still causes the contents of that to be
dumped into aclocal.m4 as well as the new m4_include line.
This is (still) because at least some of the following m4_defines used
to be AC_DEFUNs:
AC_LIBTOOL_CO
On Wed, 2004-01-14 at 12:43, Gary V. Vaughan wrote:
> What about adding m4/obsolete.m4 with:
>
> AU_DEFUN([AC_LIBTOOL_CONFIG], [AC_LIBTOOL_CONFIG])dnl
> AU_DEFUN([AC_LIBTOOL_LINKER_OPTION], [AC_LIBTOOL_LINKER_OPTION])dnl
> ...
> AU_DEFUN([AC_PROG_EGREP], [AC_PROG_EGREP])dn
It seems that Automake 1.7 isn't automatically including m4/* in the
distribution tarball, I'm not even sure why -- there's code in
/usr/bin/automake-1.7 to do just that.
I'm going to see whether we can hack around this, but to be honest, I
don't see any problem with requiring 1.8 for our bootstra
On Fri, 2004-01-16 at 16:49, Bob Friesenhahn wrote:
> On Fri, 16 Jan 2004, Scott James Remnant wrote:
> >
> > I'm going to see whether we can hack around this, but to be honest, I
> > don't see any problem with requiring 1.8 for our bootstrap now -- it
> >
On Thu, 2004-01-22 at 13:55, Peter O'Gorman wrote:
> Nick Hudson wrote:
>
> | Is the libtool-commit ML supposed to work anymore? I've not seen a message
> | there for sometime now.
>
> It is broken.
>
But we do co-ordinate all patches, even trivial ones, on
[EMAIL PROTECTED] -- so you can see w
The Libtool Team is pleased to announce the release of GNU Libtool
1.5.2.
GNU Libtool hides the complexity of using shared libraries behind a
consistent, portable interface. GNU Libtool ships with GNU libltdl,
which hides the comlexity of loading dynamic runtime libraries (modules)
behind a consis
On Mon, 2004-01-26 at 23:30, Kevin Ryde wrote:
> Scott James Remnant <[EMAIL PROTECTED]> writes:
> >
> > ftp://ftp.gnu.org/gnu/libtool/libtool-1.5-1.5.2.diff.gz
>
> This doesn't seem to have the changes to the generated files,
> therefore requiring a
On Wed, 2004-01-28 at 15:15, Daniel Reed wrote:
> On 2004-01-25T14:47-0000, Scott James Remnant wrote:
> ) The Libtool Team is pleased to announce the release of GNU Libtool
> ) 1.5.2.
>
> Since there does not appear to be any C++ code (.cc, .cxx, .C) in libtool,
> would it b
On Wed, 2004-01-28 at 14:18, Florian Bachmann wrote:
> I am trying to produce a 64bit shared library on a IRIX 6.5 (MIPS4)
> machine using the GNU toolchain (gcc, autoconf, automake, libtool).
> I am configuring gcc to produce 64bit binaries with CC="gcc -mabi=64".
> Libtool correctly picks up the
On Wed, 2004-01-28 at 20:29, Braden McDaniel wrote:
> Why are the libtool macros being installed to $(pkgdatadir) rather than
> $(datadir)/aclocal?
>
Because aclocal is slowly being deprecated, and will eventually vanish
entirely. Managing Autoconf macros really isn't a job for Automake.
The n
On Wed, 2004-01-28 at 22:26, Albert Chin wrote:
> On Wed, Jan 28, 2004 at 10:13:21PM +0000, Scott James Remnant wrote:
> > One day a version of Autoconf will use these, but for now when you run
> > aclocal it'll add an "m4_include" line to aclocal.m4 for each o
On Thu, 2004-01-29 at 01:35, Daniel Reed wrote:
> On 2004-01-28T15:59-0000, Scott James Remnant wrote:
> ) On Wed, 2004-01-28 at 15:15, Daniel Reed wrote:
> ) > Since there does not appear to be any C++ code (.cc, .cxx, .C) in libtool,
> ) > would it be possible for the next rel
On Thu, 2004-01-29 at 12:00, Peter O'Gorman wrote:
> Scott James Remnant wrote:
>
> | That's actually an Autoconf macro that's failing, unfortunately. It's
> | an irritant, but I've not figured out a way of getting around it short
> | of overriding AC_M
On Thu, 2004-02-05 at 03:40, name wrote:
> Why doesn't installation copy libtool.m4 to aclocal?
>
Assuming you are talking about CVS HEAD (libtool 1.5a, future 1.6
release) this is because libtoolize now copies libtool.m4 from its own
data directory into your macro directory.
"Your macro directo
On Tue, 2004-02-17 at 13:27, Peter O'Gorman wrote:
> Michael Pruett wrote:
> | The change you suggested fixed the first problem but not the second.
>
> We probably need to go through ltmain.in and modify every line containing
> pwd we find, then modify every line that uses the vars that were assi
On Sun, 2004-03-14 at 14:51, Peter O'Gorman wrote:
> I'll probably have some free time toward the end of this month, and am
> volunteering to roll a release of branch-1-5 if nobody has any objections.
>
> Would that be 1.5.4 or 1.5.3?
>
1.5.4 :-)
Scott
--
Have you ever, ever felt like this?
Ha
On Sun, 2004-03-14 at 17:47, Albert Chin wrote:
> On Sun, Mar 14, 2004 at 03:00:27PM +0000, Scott James Remnant wrote:
> > On Sun, 2004-03-14 at 14:51, Peter O'Gorman wrote:
> >
> > > I'll probably have some free time toward the end of this month, and am
>
On Thu, 2004-02-05 at 19:18, [EMAIL PROTECTED] wrote:
Sorry about the late reply, but here goes...
> I have a situation where I'm constructing a filesystem image, and I need
> to use the contents of that image to build new packages to be installed
> in the image. For example, I have $ROOT, which
On Wed, 2004-01-28 at 18:05, Matthew Zeits wrote:
> I am working on a project that should compile both globally--with prefix
> unset so install goes to /usr/local/ and with prefix set to an arbitrary
> directory. When the program links, even if I define an -L or an rpath,
> it looks to /usr/lo
On Thu, 2004-02-12 at 17:08, Pieter Grimmerink wrote:
> I have a strange situation with libtool (version 1.4.3), I'm wondering what I
> could do to make it work.
>
This is yet another result of the bug that Libtool would ignore the -L
option for non-libtool libraries, and instead pick a library
On Thu, 2004-03-04 at 12:17, Tietz Fabian (AA/ESW1) wrote:
> Im trying to crosscompile a c++ shared Library for a Mips target
> System using libtool.
> Unfortunately linking fails, because of libtool trying
> to link against "/usr/lib/libstdc++.so", which is the X86 Version
> of the Library, not t
On Sun, 2004-03-07 at 22:23, Patrick Welche wrote:
> LT_INIT is defined using AC_DEFUN_ONCE. There is no documentation for
> this macro in autoconf.texi, and aclocal doesn't know about it, or at
> least, it doesn't pick up the fact that as LT_INIT appears in configure.ac,
> it should include m4/li
On Fri, 2004-02-13 at 20:07, Albert Chin wrote:
> ltmain.in prints out a warning when it thinks the .la file isn't in
> $libdir:
> if test "$absdir" != "$libdir"; then
> $echo "$modename: warning: \`$deplib' seems to be moved" 1>&2
> fi
>
> However, if $absdir has "..", and it resolves to
On Wed, 2004-03-10 at 16:48, Gary V. Vaughan wrote:
> Patrick Welche wrote:
> | libtool.m4 contains:
> |
> | # serial 49 AC_PROG_LIBTOOL
> | AC_DEFUN_ONCE([LT_INIT],
> | AU_DEFUN([AC_PROG_LIBTOOL], [LT_INIT])
> | AU_DEFUN([AM_PROG_LIBTOOL], [LT_INIT])
> |
> |>From the above, libtoo
On Mon, 2004-04-05 at 14:12, Jens Petersen wrote:
> Albert, Thank you for looking at the patch, and sorry for taking
> too long to follow up to your comments. (please see below)
>
> AC> You reset sys_lib_dlsearch_path_spec.
>
> AC> So, do you want to add to sys_lib_dlsearch_path_spec?
>
On Tue, 2004-04-13 at 22:39, Alexandre Duret-Lutz wrote:
> Is it done or is there any obstacle to it? I'm dreaming about
> Automake 1.9, and if possible I would like to include support
> for this.
>
The current interface should be pretty good, trace for invocations of
_LT_TAG and the first argum
On Wed, 2004-04-14 at 08:00, Alexandre Duret-Lutz wrote:
> >>> "Scott" == Scott James Remnant <[EMAIL PROTECTED]> writes:
>
> Scott> On Tue, 2004-04-13 at 22:39, Alexandre Duret-Lutz wrote:
> >> Is it done or is there any obstacle to it? I'm
On Wed, 2004-04-14 at 18:45, Alexandre Duret-Lutz wrote:
> Ah, thanks! Sorry for being dense, but since it takes
> tag names as argument, why is it called _LT_LANG?
>
Because it actually takes language configuration names, which just
happen to be the same as the tags that get generated. (Ther
On Sat, 2004-04-17 at 22:48, Alexandre Duret-Lutz wrote:
> >>> "Scott" == Scott James Remnant <[EMAIL PROTECTED]> writes:
>
> Scott> On Wed, 2004-04-14 at 18:45, Alexandre Duret-Lutz wrote:
> >> Ah, thanks! Sorry for being dense, but since i
On Sat, 2004-05-15 at 02:27 -0400, Braden McDaniel wrote:
> I'm getting this warning (using libtool 1.5.6):
>
> libtool: link: warning: ignoring multiple `-rpath's for a libtool library
>
> I'm trying to build a module and I'm only explicitly adding one rpath in
> LDFLAGS. The first one
On Wed, 2004-05-26 at 08:07 +0200, Szombathelyi GyÃrgy wrote:
> > Yes, I read the thread. I agree that libtool should perform the
> > optimization you want but I don't see it as something that is a
> > show-stopper.
> >
> I agree that it isn't a show-stopper, but it would be very nice if
> libto
On Wed, 2004-06-16 at 21:23 +0200, Alexandre Duret-Lutz wrote:
> >>> "Gary" == Gary V Vaughan <[EMAIL PROTECTED]> writes:
>
> [...]
>
> Gary> FYI: I've made CVS libtoolize take its files from $aclocaldir again.
>
> Great! Thanks for doing this.
>
> Does it also handle the case where AC_CONFIG
On Wed, 2004-11-03 at 15:08 +0100, Christoph Wellner wrote:
> I have a problem with libtool-1.5.6, when I want to start my compiled app,
> I get an error-message, that some libraries are not found:
>
> /home/chwellner/nmm2_sarge/apps/clic/.libs/lt-clic: error while loading
> shared libraries:
On Tue, 2004-11-09 at 14:24 +, Gary V. Vaughan wrote:
> > 5. Think about speed, compile mode needs to be as fast as possible, can
> > it be faster than it is?
>
> 6. Absorb the functionality of the aberration called pkg-config. Libtool
> already has all the information it needs, we just
On Tue, 2004-11-09 at 16:29 +0100, Ralf Wildenhues wrote:
> 6. Versioned libraries. Although this is not very portable yet, it is a
> concept which IMHO needs support. Many people ask for it.
>
One of the principal problems is that you need to record when symbols
were added to the library to ge
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
> maybe a subsidiary script) to spit out link flags after poking around
> in a
On Wed, 2004-11-10 at 13:25 +, Gary V. Vaughan wrote:
> Peter O'Gorman wrote:
> > Well, I haven't thought about it really, I was vaguely imagining running
> > a perl script during bootstrap which would take the bits and pieces and
> > put them all together. I am told that xslt could do this to
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
On Wed, 2004-11-10 at 14:57 -0800, Paul Eggert wrote:
> As a special exception to the GNU General Public License, if you
> distribute this file as part of a package that automatically derives
> from this file a configuration script (and perhaps some associated
> intermediate files), then you may d
On Fri, 2004-11-12 at 11:20 +, Gary V. Vaughan wrote:
> Albert Chin wrote:
> > On Wed, Nov 10, 2004 at 03:43:48PM +0000, Scott James Remnant wrote:
> >
> > Ick. Libtool is about portably building/using libraries. Why can't we
> > leave it at that?
>
> B
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 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 Sun, 2004-11-14 at 13:35 -0500, Daniel Reed wrote:
> On 2004-11-14T08:50-0000, 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 libto
On Sun, 2004-11-14 at 17:37 -0800, Jacob Meuser wrote:
> On Sun, Nov 14, 2004 at 08:53:15AM +0000, 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
>
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
>
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 n
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
On Mon, 2004-11-15 at 15:51 +, Joe Orton wrote:
> On Mon, Nov 15, 2004 at 02:42:51PM +0000, Scott James Remnant wrote:
> > On Mon, 2004-11-15 at 13:16 +, Gary V. Vaughan wrote:
> >
> > > Ralf Wildenhues wrote:
> > > >>>>Scott James Remna
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
On Mon, 2004-11-15 at 10:51 -0800, Jacob Meuser wrote:
> On Mon, Nov 15, 2004 at 03:45:10PM +0000, 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-produ
On Tue, 2004-11-16 at 11:15 -0800, Jacob Meuser wrote:
> On Tue, Nov 16, 2004 at 03:02:55PM +0000, 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
>
On Wed, 2004-11-24 at 10:19 +0100, Ralf Wildenhues wrote:
> Libtool and inter-library dependencies
> ==
>
> needed-following linker:
> A system with a needed-following linker has a means to record
> dependencies on other libraries within a library (based on the
On Thu, 2004-12-02 at 18:36 -0500, Daniel Reed wrote:
> Is there any chance .multilib2 can be incorporated into 1.5.12? As written,
> it simply causes libtool to ask gcc to find .la files if gcc is in use. It
> should have no impact on non-gcc builds and should not cause any files to be
> missed (
91 matches
Mail list logo
