} -o testpython.la -rpath `pwd`
-module -avoid-version $PYTHON_LIB_LOC testpython.lo $PYTHON_LIBS
$PYTHON_EXTRA_LIBS /dev/null 21 \
grep 'dlname.*testpython' testpython.la /dev/null 21; then
result=yes
Any idea what the best approach to porting these would be?
Scott
--
Scott James Remnant
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 configure.ac
to test compilation
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 is a digitally signed message part
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 (the
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 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
work anywhere else?
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 doesn't
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 puts
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
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 Libtool
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.
What does
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? I'll defer to Scott
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 I
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 to deal with platforms like
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 using
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 used to
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 needs.
I
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 gtk/gtkbutton.h' for example
and require -I/usr/include/gtk-2.0 to
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
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 need
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 get
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 too. The
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 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_MACRO_DIR isn't
On Wed, 2004-05-26 at 08:07 +0200, Szombathelyi Gyrgy 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
libtool could
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
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 it takes
tag names as argument, why is it called _LT_LANG
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 dreaming about
Automake 1.9, and if possible I would like
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.
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 argument
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 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
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 the
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 12
fi
However, if $absdir has .., and it resolves to $libdir taking
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, libtoolize
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?
Had
On Sun, 2004-03-14 at 17:47, Albert Chin wrote:
On Sun, Mar 14, 2004 at 03:00:27PM +, 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
volunteering to roll a release of branch-1-5
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 assigned
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 directory
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_MSG_ERROR.
Well, we already know the results
On Wed, 2004-01-28 at 15:15, Daniel Reed wrote:
On 2004-01-25T14:47-, 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 be possible for the next
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 SGI
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 new
On Wed, 2004-01-28 at 22:26, Albert Chin wrote:
On Wed, Jan 28, 2004 at 10:13:21PM +, 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 of these
files (rather than including them
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 re-autoconf etc. I think a diff is normally
meant
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
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 what
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
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
significantly reduces the size of our tar.gz
I
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])dnl
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:
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 confirm that
the
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 meet.
If the Libtool Team were to ever meet, we
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 versions only in $prefix/share/libtool
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
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 make
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 the rest of the argument
| parsing to make
:29.0 +
+++ libtool-CVS/ChangeLog 2003-12-07 18:59:19.0 +
@@ -0,0 +1,7 @@
+2003-12-07 Scott James Remnant [EMAIL PROTECTED]
+
+ * ltmain.in: Move the code to infer the tagged configuration in
+ link mode until after the argument parsing again, so $base_compile
+ contains
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.
Gah! That has got to be a bug
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?
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 means that aclocal has found
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
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 bootstrap script says:
# Helps bootstrapping libtool
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
myself (I assume you've already done
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
architectures
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 seems like a good compromise, I imagine
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 accustomed to
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 release
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 if
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
maintainers to update their libtools. My
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
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
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 the Debian Libtool package maintainer, I'd like to know whether
-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.
-- Kirk, Errand of Mercy, stardate 3198.4
--
Scott James Remnant Have you ever
77 matches
Mail list logo
