AIX sends messages like /bin/expr: Arg list too long to stderr.
These should be ignored. Patch attached against CVS head.
2005-08-04 Albert Chin-A-Young [EMAIL PROTECTED]
* config/ltmain.m4sh: Ignore errors from expr when
determining if piece-wise linking should be done
know
what else to offer. What do you mean by loading code is now different
for builtin vs modules? Why would you have to load code for builtins?
Couldn't you lt_dlsym() to determine if the module was a
builtin/already loaded?
--
albert chin ([EMAIL PROTECTED
libmonacoxml++.la -rpath
/udd001/hoops/usr/lib version.lo ../rtxsrc/libosysrt++.la
../rtxmlsrc/libosysrtxml++.la eod/libmonacoxmleod++.la -lxml2 -liconv
-lnsl -lsocket -lz -lm -lc
Please attached the output of:
$ /bin/bash -x ../../libtool --tag=CC ...
--
albert chin ([EMAIL PROTECTED
On Fri, Jul 22, 2005 at 10:14:56AM +0200, Peter Ekberg wrote:
2005-07-21 Peter Ekberg [EMAIL PROTECTED]
* m4/libtool.m4 (_LT_PROG_F77): Set it up so that saying F77=:
to configure disables the fortran tests in the testsuite.
Ick. Why not just F77=?
--
albert chin ([EMAIL
On Fri, Jul 22, 2005 at 10:15:05AM +0200, Peter Ekberg wrote:
2005-07-21 Peter Ekberg [EMAIL PROTECTED]
* m4/libtool.m4 (_LT_LINKER_OPTION): Fix copy-paste bug, it is
the linker that is tested.
Looks good.
--
albert chin ([EMAIL PROTECTED])
. Instead make distclean; ./configure --disable-shared, because
then debugging with gdb is a lot easier.
How do you propose as an alternate portable solution? What do we do on
systems that require setting LIBPATH/LD_LIBRARY_PATH/SHLIB_PATH for
the in-build-directory binary to work?
--
albert
about:
-chown -R root $(DESTDIR)$(ltdldatadir) 2/dev/null
-chgrp -R root $(DESTDIR)$(ltdldatadir) 2/dev/null
I like this too.
--
albert chin ([EMAIL PROTECTED])
On Sun, Jul 10, 2005 at 11:34:13AM +0900, Peter O'Gorman wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Albert Chin wrote:
|05:00 PM dogbert ~$PS1='$ ' /bin/sh
|$ echo Xbla | sed 1s,^X,,
|X,,: not found
|$ sed: Function 1s, cannot be parsed.
|
|
| What system is this? Works
haven't seen any responses to this, so I will: it does need it quoted:
05:00 PM dogbert ~$PS1='$ ' /bin/sh
$ echo Xbla | sed 1s,^X,,
X,,: not found
$ sed: Function 1s, cannot be parsed.
What system is this? Works fine on 4.0D and 5.1.
--
albert chin ([EMAIL PROTECTED
.
But libtool does not compute the SONAME across all platforms the same.
--
albert chin ([EMAIL PROTECTED])
___
http://lists.gnu.org/mailman/listinfo/libtool
domain, which
is more or less a namespace for libraries.
Is there online documentation for this? Perhaps this:
http://www.unet.univie.ac.at/aix/aixprggd/genprogc/loader_domains.htm
--
albert chin ([EMAIL PROTECTED])
___
http://lists.gnu.org/mailman
On Sun, May 15, 2005 at 06:35:33AM +0200, Ralf Wildenhues wrote:
Hi Albert,
* Albert Chin wrote on Sun, May 15, 2005 at 04:27:05AM CEST:
* ltmain.in: New variable quote_scanset to work around SunOS ksh
`case' backslash-escaping bug: protect character class by variable
expansion
On Wed, May 18, 2005 at 08:33:01AM +0200, Ralf Wildenhues wrote:
* Albert Chin wrote on Tue, May 17, 2005 at 11:04:33PM CEST:
On Sun, May 15, 2005 at 06:35:33AM +0200, Ralf Wildenhues wrote:
* Albert Chin wrote on Sun, May 15, 2005 at 04:27:05AM CEST:
case foobar
libtool: compile: libobj name `ltdl.lo' may not contain shell special
characters.
*** Exit 1
This is a result of the ksh bug.
--
albert chin ([EMAIL PROTECTED])
___
http://lists.gnu.org/mailman/listinfo/libtool
Feb 7 2003 /usr/bin/posix/sh
--
albert chin ([EMAIL PROTECTED])
___
http://lists.gnu.org/mailman/listinfo/libtool
clever about letting me have
multiple libraries of different major versions, is there any
equivalent way to handle the header files of different versions?
Take a look at the way glib handles this. The encode the ABI in the
library name and the path to the include files.
--
albert chin ([EMAIL
's/#.*//;s/[:,]/ /g;s/=[^=]*$//;s/=[^= ]* / /g;/^$/d' | tr '\n' ' '`
sys_lib_dlsearch_path_spec=/lib /usr/lib $lt_ld_extra
fi
Why force /lib /usr/lib first here?
--
albert chin ([EMAIL PROTECTED])
___
http://lists.gnu.org/mailman/listinfo
On Sat, May 14, 2005 at 04:14:14PM -0500, Albert Chin wrote:
Moreoever, libtool.m4 has (from the 2.0 branch):
# Append ld.so.conf contents to the search path
if test -f /etc/ld.so.conf; then
lt_ld_extra=`awk '/^include / { system(sprintf(cd /etc; cat %s,
\[$]2)); skip = 1
statement.
--
albert chin ([EMAIL PROTECTED])
___
http://lists.gnu.org/mailman/listinfo/libtool
| $NL2SP`
Can you explain how the latter is faster? From inspection, I'd believe
the first to be faster.
--
albert chin ([EMAIL PROTECTED])
; echo \$dlname'\''`~
dlpath=$dir/\$dldll~
$RM \$dlpath'
shlibpath_overrides_runpath=yes
So, some values using '~' use a newline after, and some don't. Does it
matter or should we have some consistency?
--
albert chin ([EMAIL PROTECTED
?
Unless the GCC folks are using some version of libtool-1.5.x, you
should open a bug report with them.
--
albert chin ([EMAIL PROTECTED])
___
http://lists.gnu.org/mailman/listinfo/libtool
. It is
the use of -nostdlib that I am most interested in. Will that usage
continue?
What's the value of $postdep_objects?
--
albert chin ([EMAIL PROTECTED])
___
http://lists.gnu.org/mailman/listinfo/libtool
On Tue, Mar 08, 2005 at 03:38:28PM +0100, Ralf Wildenhues wrote:
* Albert Chin wrote on Tue, Mar 08, 2005 at 03:21:58PM CET:
On Tue, Mar 08, 2005 at 10:10:35AM +0100, Ralf Wildenhues wrote:
* Albert Chin wrote on Fri, Mar 04, 2005 at 04:33:39AM CET:
That won't help. After you copy
link the .a files. I see no reason why we
extract the convenience libraries libraries when linking against the
compiler v. the linker.
--
albert chin ([EMAIL PROTECTED])
___
http://lists.gnu.org/mailman/listinfo/libtool
On Thu, Mar 03, 2005 at 11:41:00AM -0600, Albert Chin wrote:
When using the compiler to perform the link and linking against
convenience libraries, is there any reason to link explicitly against
the extracted objects of the convenience libraries rather than just
the .a file? I'm running
On Thu, Mar 03, 2005 at 01:23:44PM -0600, Albert Chin wrote:
Will bad things happen if -no_prelink is used in combination with CC
-ar? When GNU libtool creates an archive library which is comprised of
objects from other libtool archive libraries (convenience libraries),
it extracts the object
On Fri, Mar 04, 2005 at 10:19:02AM +0900, Peter O'Gorman wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Albert Chin wrote:
| On Thu, Mar 03, 2005 at 01:23:44PM -0600, Albert Chin wrote:
|
| Ok, this sucks. -no_prelink causes other problems. The SGI compiler
| leaves template
On Thu, Mar 03, 2005 at 12:01:26PM -0600, Bob Friesenhahn wrote:
On Thu, 3 Mar 2005, Albert Chin wrote:
When using the compiler to perform the link and linking against
convenience libraries, is there any reason to link explicitly against
the extracted objects of the convenience libraries
On Thu, Mar 03, 2005 at 09:39:36PM -0600, Albert Chin wrote:
On Thu, Mar 03, 2005 at 12:01:26PM -0600, Bob Friesenhahn wrote:
On Thu, 3 Mar 2005, Albert Chin wrote:
When using the compiler to perform the link and linking against
convenience libraries, is there any reason to link
generating config bits in the current directory/.libs or
so.
I agree!
--
albert chin ([EMAIL PROTECTED])
:
/usr/lib/libtest.0.dylib (No such file or directory, errno = 2)
./libtool-1.5.14-darwin-error.sh: line 34: 8145 Trace/BPT trap
bar/testprog
---(snip!)---
Maybe the same error Bob fixed with?
http://lists.gnu.org/archive/html/libtool-patches/2004-11/msg00290.html
--
albert chin ([EMAIL
On Thu, Feb 24, 2005 at 12:40:23AM -0600, Bob Friesenhahn wrote:
On Wed, 23 Feb 2005, Albert Chin wrote:
Just build ImageMagick-6.1.9 which uses a single Makefile for
subdirectory builds (rather than a Makefile per directory). Some of
the tests fail because the wrapper script created
/opt/TWWfsw/libttf21/lib
-R/opt/TWWfsw/libttf21/lib:/opt/TWWfsw/zlib11/lib -lfreetype
-L/opt/TWWfsw/zlib11/lib -lz -L/opt/TWWfsw/libxml26/lib -o
Magick++/tests/exceptions Magick++/tests/exceptions.o
Magick++/lib/libMagick++.la
--
albert chin ([EMAIL PROTECTED
or -qarch=ppc64 in CFLAGS.
If you want System V-style shared libraries, LDFLAGS=-Wl,-brtl.
--
albert chin ([EMAIL PROTECTED])
___
http://lists.gnu.org/mailman/listinfo/libtool
does not work for some reason yet unknown
to me. But one is better than none, no?
Rebuild with LDFLAGS=-Wl,-brtl.
--
albert chin ([EMAIL PROTECTED])
___
http://lists.gnu.org/mailman/listinfo/libtool
On Thu, Jan 13, 2005 at 07:32:46PM +0100, Peter Ekberg wrote:
Albert Chin wrote:
On Tue, Jan 11, 2005 at 06:31:19PM +0100, Peter Ekberg wrote:
When installing a libtool module on aix 4.2, the .so file is not
installed, even though the .la file specifies:
dlname='x.so'
Copying x.so
hard to fix in libtool. It's wrong though.
--
albert chin ([EMAIL PROTECTED])
___
http://lists.gnu.org/mailman/listinfo/libtool
, not the linker. Do you mean
-lpthread?
--
albert chin ([EMAIL PROTECTED])
___
http://lists.gnu.org/mailman/listinfo/libtool
-line).
--
albert chin ([EMAIL PROTECTED])
___
Libtool mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/libtool
.)? It
seems way too Linux-specific to me.
--
albert chin ([EMAIL PROTECTED])
___
Libtool mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/libtool
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
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-config. Libtool
on platforms that need it, and not on
Linux for example.
Ick. Libtool is about portably building/using libraries. Why can't we
leave it at that?
--
albert chin ([EMAIL PROTECTED])
___
Libtool mailing list
[EMAIL PROTECTED]
http://lists.gnu.org
make sure they all accept -D[var]).
--
albert chin ([EMAIL PROTECTED])
___
Libtool mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/libtool
, the
embedded runtime path will be the path to the library from the build
directory, not the installed library directory. So, regardless of
whether or not libtool is used, order matters.
--
albert chin ([EMAIL PROTECTED])
___
Libtool mailing list
[EMAIL
their behavior though.
--
albert chin ([EMAIL PROTECTED])
___
Libtool mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/libtool
On Tue, Sep 14, 2004 at 01:29:31PM +0100, Gary V. Vaughan wrote:
Albert Chin wrote:
On Tue, Sep 14, 2004 at 11:55:20AM +0100, Gary V. Vaughan wrote:
Maybe we could mandate that option arguments to be passed through
libtool have to be mangled? So we'd accept, say, -Woff=all and
unmangle
On Tue, Sep 14, 2004 at 06:30:41PM +0100, Gary V. Vaughan wrote:
But first: Do we revert the patches? -1 from me, +1 from Bob so far...
I just submitted a patch to do this so +1 from me :)
--
albert chin ([EMAIL PROTECTED])
___
Libtool mailing
and
passes parts through incorrectly then the compiler will no longer
compile. It is better to reject/ignore the entire option if it
would otherwise not be passed correctly.
Yes!
--
albert chin ([EMAIL PROTECTED])
___
Libtool mailing list
[EMAIL
.
--
albert chin ([EMAIL PROTECTED])
___
Libtool mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/libtool
one `-').
--
albert chin ([EMAIL PROTECTED])
___
Libtool mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/libtool
On Sat, Jun 05, 2004 at 09:54:03PM +0200, Stephane Bortzmeyer wrote:
On Wed, Jun 02, 2004 at 12:51:31PM -0500,
Albert Chin [EMAIL PROTECTED] wrote
a message of 21 lines which said:
Does this work:
AC_SEARCH_LIBS(dlopen, [-ldl])
This will add -ldl to $LIBS if needed. I think
in.
--
albert chin ([EMAIL PROTECTED])
___
Libtool mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/libtool
On Tue, May 25, 2004 at 11:37:38AM +0200, Szombathelyi_GyXrgy wrote:
On Mon, 24 May 2004, Albert Chin wrote:
dependency_libs doesn't contain just libraries. Maybe LDFLAGS as well,
like -pthread. BTW, is it _really_ a problem to link against
everything in dependency_libs? Indirectly
dependency_libs doesn't contain just libraries. Maybe LDFLAGS as well,
like -pthread. BTW, is it _really_ a problem to link against
everything in dependency_libs? Indirectly, this is going to happen
anyway even if libtool doesn't do this.
--
albert chin ([EMAIL PROTECTED
On Mon, May 24, 2004 at 07:32:01PM -0500, Bob Friesenhahn wrote:
On Mon, 24 May 2004, Albert Chin wrote:
On Mon, May 24, 2004 at 08:19:00AM +0200, Szombathelyi Gy?rgy wrote:
I've just curious if is it possible _not_ to link a program/lib against
its indirect dependencies. I mean if libC
On Sun, May 02, 2004 at 06:24:50PM -0500, Bob Friesenhahn wrote:
On Sun, 2 May 2004, Albert Chin wrote:
On Sun, May 02, 2004 at 01:47:09PM -0500, Bob Friesenhahn wrote:
I am encountering a problem with gcc 3.4.0 in that when libtool
performs a C++ link, it includes -L options which
multiple ABIs?
I don't think libtool should support this. What if you wanted to build
a 64-bit version of libpng which depends on libz? How do you specify
the path to the 64-bit libz? libtool cannot fully support what you
want.
I'm in favor of keeping things simple as they are now.
--
albert
) and
possibly include files, if the include files are specific to the
compiler.
--
albert chin ([EMAIL PROTECTED])
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
be using the C++ compiler to link
anyway.
--
albert chin ([EMAIL PROTECTED])
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
On Thu, Apr 15, 2004 at 02:43:57PM -0500, Bob Friesenhahn wrote:
On Fri, 16 Apr 2004, Albert Chin wrote:
On Thu, Apr 15, 2004 at 11:10:20AM -0500, Bob Friesenhahn wrote:
If a program which is based on C language depends on a library which
is implemented in C++, the C++ compiler should
to it, I'll try and look at
this next week.
I already have it done for Solaris, HP-UX, Tru64 UNIX, and IRIX. My
patch is for the 1.5 branch. I'll forward-port to the 1.6 branch and
post the patch in a few days when I have time.
--
albert chin ([EMAIL PROTECTED
On Tue, Apr 13, 2004 at 10:42:05PM +0100, Gary V.Vaughan wrote:
On 14 Apr 2004, at 18:55, Albert Chin wrote:
I already have it done for Solaris, HP-UX, Tru64 UNIX, and IRIX. My
patch is for the 1.5 branch. I'll forward-port to the 1.6 branch and
post the patch in a few days when I have time
has pthread_*
symbols but no libpthread/libthread as a result of the above.
--
albert chin ([EMAIL PROTECTED])
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
.
The modules do all load ok under Linux, Solaris, AIX, IRIX, and HP-UX.
Is anyone aware of FreeBSD-specific issues with module loading? Is
there some resource limit that may be expended?
Tried upgrading to the latest 5.x release or 5-CURRENT?
Nothing in sysctl -a stands out to me.
--
albert
, it is difficult to see how relinking would work.
Why not just have the developer write a Makefile.am so the libraries
are built/installed in the correct order?
--
albert chin ([EMAIL PROTECTED])
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org
then it should be...
Yes, it should be. BTW, how do we handle the case where
need_lib_prefix!=no?
--
albert chin ([EMAIL PROTECTED])
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
it's preferring
libraries with corresponding .la files. Even that is a bug though.
Someone needs to dig further.
--
albert chin ([EMAIL PROTECTED])
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
On Fri, Feb 13, 2004 at 02:07:12PM -0600, 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 look much at the problem, but thought I would
report it. Please let me know if I can provide additional information.
I noticed this too but haven't had a chance to look into it. Maybe
this weekend.
--
albert chin ([EMAIL PROTECTED])
___
Libtool
have VERBOSE=1
set the tests will be more verbose.
--
albert chin ([EMAIL PROTECTED])
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
looks like the following:
relink_command=(cd /home/michael/my code/src; ...)
Search your libtool script for a line like:
relink_command=(cd `pwd`; ...
and change it to:
relink_command=(cd \`pwd`\; ...
Does that fix it?
--
albert chin ([EMAIL PROTECTED
to be told where to look at runtime. LDFLAGS looks like this:
-L/usr/local/lib -Wl,-rpath /usr/local/lib
You should use -Wl,-rpath,/usr/local/lib
^
--
albert chin ([EMAIL PROTECTED])
___
Libtool mailing list
[EMAIL PROTECTED]
http
On Fri, Feb 13, 2004 at 10:52:02AM -0800, johnny henrik wrote:
How do I configure libtool to work with CC compiler?
Please give my some pointer/link ...
Build it just like you did to create /usr/local/bin/libtool but use
The Sun C compiler (i.e. CC=cc CFLAGS=blah).
--
albert chin ([EMAIL
do we solve
this? (cd $absdir; /bin/pwd) won't work because of automounter
madness.
Or should we just remove the message?
--
albert chin ([EMAIL PROTECTED])
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
| ${SED} 's%^.*/%%'`
modename=$progname
to:
# The name of this program.
progname=`$echo $0 | ${SED} 's%^.*/%%'`
full_path_progname=$0
modename=$progname
and then we can use $full_path_progname in func_infer_tag().
--
albert chin ([EMAIL PROTECTED
On Wed, Feb 11, 2004 at 07:02:00PM +, Gary V. Vaughan wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Albert Chin wrote:
| So this means func_infer_tag() is broken in branch-1-5 because it does
| this:
| func_infer_tag () {
| if test -n $available_tags test -z $tagname
-L/home/john/
common/gpslib/source/build/output/sol/lib -L/lib -lc
You cannot use a libtool configured for GCC with the Sun compiler.
Each libtool script is custom-generated for a specific compiler.
--
albert chin ([EMAIL PROTECTED])
___
Libtool
the libraries in dependency_libs come after the library? Or
am I missing something?
--
albert chin ([EMAIL PROTECTED])
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
to the package using them?
--
albert chin ([EMAIL PROTECTED])
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
Why does win32_libid() in ltmain.in use grep -E rather than $EGREP?
--
albert chin ([EMAIL PROTECTED])
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
for building 64-bit C++ libraries with the
vendor C++ compiler. Do we need to do something similar? Or is it
easier for us to say that if $LD == $CC for a tag, any unrecognized
options are passed to $compiler_flags?
--
albert chin ([EMAIL PROTECTED])
___
Libtool
++ compiler. Do we need to do something similar? Or is it
easier for us to say that if $LD == $CC for a tag, any unrecognized
options are passed to $compiler_flags?
--
albert chin ([EMAIL PROTECTED])
___
Libtool mailing list
[EMAIL PROTECTED]
http
On Tue, Dec 16, 2003 at 11:33:15AM +, Gary V. Vaughan wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Albert Chin wrote:
| Repost as the first try didn't garner a response.
|
| If I invoke libtool as so:
| $ libtool ... [path to shared library] ...
| is libtool suppose to pass
Repost as the first try didn't garner a response.
If I invoke libtool as so:
$ libtool ... [path to shared library] ...
is libtool suppose to pass [path to shared library] to the final link
stage? It's ignoring anything on the command line that ends with
*$shrext.
--
albert chin ([EMAIL
case, so when I set CC to (on darwin) gcc -arch ppc -arch i386 and set
CXX to g++ -arch ppc -arch i386 I expected (without having looked at
the code) tag inference to work. It doesn't of course.
Before the case, what is the output of:
echo .$CC.
--
albert chin ([EMAIL PROTECTED
It was mentioned recently on this list.
--
albert chin ([EMAIL PROTECTED])
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
++? And, the --enable-shared and --enable-static options would have
to multiply (--enable-c-shared, --enable-cxx-shared, etc).
--
albert chin ([EMAIL PROTECTED])
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
solution
has been to redefine AC_LIBTOOL_CXX_CONFIG and friends to a colon, but this
is quite of a hack. Again I ask if there is a nicer way to strip down my
already huge (750kb) configure script.
Does this help?
AC_LIBTOOL_TAGS([])
--
albert chin ([EMAIL PROTECTED
?
--
albert chin ([EMAIL PROTECTED])
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
If I invoke libtool as so:
$ libtool ... [path to shared library] ...
is libtool suppose to pass [path to shared library] to the final link
stage? It's ignoring anything on the command line that ends with
*$shrext.
--
albert chin ([EMAIL PROTECTED
.la files, but with no luck.
Any ideas on how to proceed from here?
Does this patch from Ben Reed help?
http://mail.gnu.org/archive/html/libtool-patches/2003-06/msg2.html
Or this one:
http://mail.gnu.org/archive/html/libtool/2003-10/msg00067.html
--
albert chin ([EMAIL PROTECTED
for you?
http://mail.gnu.org/archive/html/libtool/2003-10/msg00067.html
It should be trivial to apply the patch to your 1.4.3 version.
--
albert chin ([EMAIL PROTECTED])
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo
.la -lz -lpthread
-lm -ldb'
How did that /usr/lib/libxml2.la get in there?
Does this fix it (should apply to 1.5)?
--
albert chin ([EMAIL PROTECTED])
-- snip snip
Index: ltmain.in
===
RCS file: /cvsroot/libtool/libtool/ltmain.in
-avoid-version
This also removes the requirement that the library name start with lib.
This depends on the platform.
--
albert chin ([EMAIL PROTECTED])
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
On Tue, Aug 26, 2003 at 01:49:10PM +1000, Robert Collins wrote:
On Tue, 2003-08-26 at 12:58, Albert Chin wrote:
Why not use $srcfile and $srcfile.lock as the lock file? So, rather
than:
They may be on different fs's.
How is that possible? If we use $srcfile.lock as the lock file
possible solution is to ignore postdeps when creating convenience
libraries.
Any downsides to this? It does seem to make sense. And what about C
convenience libraries (or any convenience library)? Ignore postdeps
totally when creating convenience libraries?
--
albert chin ([EMAIL PROTECTED
If a compiler doesn't support -c -o, libtool creates a lock file by
hard linking the libtool binary with the lock file. This is a problem
if the libtool binary is on a different file system than the lock
file. Why don't we use a symbolic link?
--
albert chin ([EMAIL PROTECTED
but it
doesn't yet.
--
albert chin ([EMAIL PROTECTED])
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
101 - 200 of 272 matches
Mail list logo
