Sun C++
is creating a library and not a program?
--
albert chin ([EMAIL PROTECTED])
___
http://lists.gnu.org/mailman/listinfo/libtool
On Sun, Mar 02, 2008 at 07:42:53PM -0600, Albert Chin wrote:
On Mon, Mar 03, 2008 at 02:02:09AM +0200, Petteri Räty wrote:
Albert Chin kirjoitti:
On Thu, Feb 28, 2008 at 03:17:54PM +0200, Petteri Räty wrote:
[EMAIL PROTECTED] /mnt/checkouts/classpath/native/jni/qt-peer $ make
make all-am
On Mon, Mar 03, 2008 at 02:02:09AM +0200, Petteri Räty wrote:
Albert Chin kirjoitti:
On Thu, Feb 28, 2008 at 03:17:54PM +0200, Petteri Räty wrote:
[EMAIL PROTECTED] /mnt/checkouts/classpath/native/jni/qt-peer $ make
make all-am
make[1]: Entering directory `/mnt/checkouts/classpath/native/jni
but libtool moves it to the end. This happens with both 1.5.26 and cvs
head.
The fact that libtool reorders _any_ of the command-line is a bug. I
think Ralf has a fix for this but I don't think it'll happen until 2.1
or 2.2.
--
albert chin ([EMAIL PROTECTED
the development GCC i do the following:
export PATH=/home/bcosta/build/install_gcc/bin:$PATH
export LD_LIBRARY_PATH=/home/bcosta/build/install_gcc/lib:$LD_LIBRARY_PATH
What if you also set LDFLAGS=-L/home/bcosta/build/install_gcc/lib?
--
albert chin ([EMAIL PROTECTED
. And, it cannot be used to
build shared libraries. So, just add CC=gcc.
--
albert chin ([EMAIL PROTECTED])
___
http://lists.gnu.org/mailman/listinfo/libtool
. This is an issue for me as I need
the stlport4 library's definition of the std C++ library. I have had
to had patch libtool for several packages (including my own) because
of this limitation.
The latest version in CVS (both for 1.5 branch and HEAD) does this.
--
albert chin ([EMAIL PROTECTED
/X11R6/lib isn't in the default set of paths searched by
the loader?
--
albert chin ([EMAIL PROTECTED])
___
http://lists.gnu.org/mailman/listinfo/libtool
On Tue, Oct 03, 2006 at 08:16:47AM -0500, Rex Dieter wrote:
Albert Chin wrote:
I don't see how libtool can intelligently decide the minimum set of
libraries needed to satisfy the link.
pkgconfig has both
Libs =
Libs.private =
The latter being for private and/or static linking
On Tue, Oct 03, 2006 at 09:14:37PM +0200, Kurt Roeckx wrote:
Also, libtool has a problem with it, since it can reorder things.
See http://bugs.debian.org/347650
Yeah, reordering of command-line args is not nice. I think Ralf has a
patch to fix this but it's post-2.0 work.
--
albert chin
don't see how libtool can intelligently decide the minimum set of
libraries needed to satisfy the link.
--
albert chin ([EMAIL PROTECTED])
___
http://lists.gnu.org/mailman/listinfo/libtool
. It's only
an example.
Then how about:
% ./configure --prefix=/
% make
% make install DESTDIR=/blah/blah
--
albert chin ([EMAIL PROTECTED])
___
http://lists.gnu.org/mailman/listinfo/libtool
On Fri, Sep 22, 2006 at 04:52:27PM -0500, Albert Chin wrote:
On Fri, Sep 22, 2006 at 05:26:07PM -0400, Jeff Blaine wrote:
I tried DESTDIR. It doesn't do what I want. If I specify
% ./configure --prefix=/usr/local
% make
% make install DESTDIR=/blah/blah
On Tue, Sep 19, 2006 at 10:11:36AM +0200, Kent Boortz wrote:
Albert Chin [EMAIL PROTECTED] writes:
snip
So, in both cases, libz is not on the command-line used to create the
shared library.
Yes, what I meant was that I took the cc line libtool expand to,
inserted -lmysqlclient
and output.
So, with this tool, someone doesn't need the cccl Visual C++ wrapper:
http://cccl.sourceforge.net/
--
albert chin ([EMAIL PROTECTED])
___
http://lists.gnu.org/mailman/listinfo/libtool
.
--
albert chin ([EMAIL PROTECTED])
___
http://lists.gnu.org/mailman/listinfo/libtool
On Tue, Sep 19, 2006 at 05:18:08PM -0700, Noel Yap wrote:
On 9/19/06, Albert Chin [EMAIL PROTECTED] wrote:
On Tue, Sep 19, 2006 at 03:32:58PM -0700, Noel Yap wrote:
What are the proper incantations to deploy libraries and executables
from a staging area (such that the rpath correctly points
library.
On HP-UX, lib*.a libraries are always static archives, regardless of
how the members were compiled. If you want to link in
libmysqlclient_r, I think your only solution is to build it as part of
whatever program you're building but create it as a convenience
library.
--
albert chin ([EMAIL
.
--
albert chin ([EMAIL PROTECTED])
___
http://lists.gnu.org/mailman/listinfo/libtool
On Fri, Sep 08, 2006 at 04:14:27PM -0600, Eric Blake wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Albert Chin on 9/8/2006 3:54 PM:
On Fri, Sep 08, 2006 at 02:31:06PM -0600, Eric Blake wrote:
Then perhaps the right fix is making -dlpreopen on Windows be a key
On Tue, Aug 08, 2006 at 02:58:44PM -0500, Albert Chin wrote:
Another version. Patch against branch-1-5 only. I've reordered where
--export-dynamic occurs so we don't have to worry about the above.
Our use of both $export_dynamic_symbols_cmds and
$export_dynamic_flag_spec somewhat breaks
On Tue, Aug 08, 2006 at 02:58:44PM -0500, Albert Chin wrote:
Another version. Patch against branch-1-5 only. I've reordered where
--export-dynamic occurs so we don't have to worry about the above.
Our use of both $export_dynamic_symbols_cmds and
$export_dynamic_flag_spec somewhat breaks
| grep language_editor_up_button_clicked_cb
269185316 T .language_editor_up_button_clicked_cb
536936672 D language_editor_up_button_clicked_cb
--
albert chin ([EMAIL PROTECTED])
___
http://lists.gnu.org/mailman/listinfo/libtool
On Thu, Aug 17, 2006 at 08:22:08AM +0200, Ralf Wildenhues wrote:
* Albert Chin wrote on Thu, Aug 17, 2006 at 07:55:14AM CEST:
On Thu, Aug 17, 2006 at 07:42:00AM +0200, Ralf Wildenhues wrote:
But say, why is -Wl,-E not passed to the link line? It should be
export_dynamic_flag_spec
|backend_group
How do we solve this? I suppose we could build without CFLAGS but then
we'd lose +DD64 for 64-bit objects.
--
albert chin ([EMAIL PROTECTED])
___
http://lists.gnu.org/mailman/listinfo/libtool
On Thu, Aug 17, 2006 at 07:42:00AM +0200, Ralf Wildenhues wrote:
* Albert Chin wrote on Thu, Aug 17, 2006 at 12:39:25AM CEST:
Just built openldap-2.3.25 on HP-UX 11.23/IA. 'make check' fails
because a symbol wasn't available in the main binary which dlopen()'ed
a module that required
On Sun, Jul 02, 2006 at 10:58:23PM +0900, Peter O'Gorman wrote:
On Tue, 2006-06-20 at 12:12 -0500, Albert Chin wrote:
Albert also questioned the documentation:
On some operating systems, a program symbol must be specially
declared
in order to be dynamically resolved with the `dlsym
On Sun, Jul 02, 2006 at 10:58:23PM +0900, Peter O'Gorman wrote:
On Tue, 2006-06-20 at 12:12 -0500, Albert Chin wrote:
Albert also questioned the documentation:
On some operating systems, a program symbol must be specially
declared
in order to be dynamically resolved with the `dlsym
On Thu, Aug 03, 2006 at 02:50:31PM +0200, Ralf Menzel wrote:
Albert Chin [EMAIL PROTECTED] writes:
Good catch. Updated patch attached.
2006-08-01 Albert Chin [EMAIL PROTECTED]
* libtool.m4 (AC_LIBTOOL_POSTDEP_PREDEP) [ solaris ]:
Don't set $postdeps to -lCstd -lCrun
.
--
albert chin ([EMAIL PROTECTED])
On Tue, Aug 01, 2006 at 02:12:31PM +0900, Peter O'Gorman wrote:
On Aug 1, 2006, at 1:38 PM, Albert Chin wrote:
Sun C++ supports two C++ libraries, -library=Cstd (default), and the
newer -library=stlport4. They are incompatible. Therefore, libtool's
use of -lCstd (equivalent to -library
and branch-2.0 attached.
2006-07-31 Albert Chin [EMAIL PROTECTED]
* libtool.m4 (AC_LIBTOOL_POSTDEP_PREDEP) [ solaris ]:
Don't set $postdeps to -lCstd -lCrun if
-library=stlport4 set in CXXFLAGS as stlport4 C++
library incompatible with Cstd C++ library. Use
this soon.
--
albert chin ([EMAIL PROTECTED])
___
http://lists.gnu.org/mailman/listinfo/libtool
On Mon, Jul 03, 2006 at 02:20:45PM -0500, Bob Friesenhahn wrote:
A challenge is that in libtool 2.0, the libtool script is not
generated until the end of the configure script run (an
`enhancement' in 2.0) so it is not available for use.
Didn't Ralf address this?
--
albert chin ([EMAIL
On Sun, Jun 11, 2006 at 01:14:23AM -0500, Albert Chin wrote:
On Sat, Jun 10, 2006 at 07:12:34PM -0500, Albert Chin wrote:
On Sun, Jun 11, 2006 at 01:04:17AM +0200, Ralf Wildenhues wrote:
* Albert Chin wrote on Sat, Jun 10, 2006 at 08:49:29PM CEST:
On Sat, Jun 10, 2006 at 08:29:44PM +0200
Addition to TODO file. Should I expand on why this is needed or is it
obvious?
--
albert chin ([EMAIL PROTECTED])
-- snip snip
Index: TODO
===
RCS file: /cvsroot/libtool/libtool/TODO,v
retrieving revision 1.71
diff -u -p -r1.71
On Mon, Jun 19, 2006 at 07:42:40AM +0200, Ralf Wildenhues wrote:
* Albert Chin wrote on Mon, Jun 19, 2006 at 07:37:00AM CEST:
Addition to TODO file. Should I expand on why this is needed or is it
obvious?
It's obvious why you want this, and why this is needed in many
situations
* ]
hardcode_libdir_flag_spec_ld: Removed.
Reported by Roger While [EMAIL PROTECTED].
However, one entry for hardcode_libdir_flag_spec_ld remains (patch
below to remove). Did you skip this on purpose?
--
albert chin ([EMAIL PROTECTED])
-- snip snip
Index: libtool.m4
On Mon, Jun 12, 2006 at 08:05:45AM +0200, Ralf Wildenhues wrote:
Hi Albert,
* Albert Chin wrote on Mon, Jun 12, 2006 at 07:37:11AM CEST:
On Mon, Jun 12, 2006 at 07:25:32AM +0200, Ralf Wildenhues wrote:
* Ralf Wildenhues wrote on Thu, Jan 05, 2006 at 02:03:49PM CET:
* Albert Chin wrote
On Mon, Jun 12, 2006 at 07:25:32AM +0200, Ralf Wildenhues wrote:
* Ralf Wildenhues wrote on Thu, Jan 05, 2006 at 02:03:49PM CET:
* Albert Chin wrote on Wed, Jan 04, 2006 at 11:49:35PM CET:
On Wed, Jan 04, 2006 at 10:19:27AM +0100, Roger While wrote:
Libtool 1.5.22
There is a problem
On Mon, Jun 12, 2006 at 07:25:32AM +0200, Ralf Wildenhues wrote:
* Ralf Wildenhues wrote on Thu, Jan 05, 2006 at 02:03:49PM CET:
* Albert Chin wrote on Wed, Jan 04, 2006 at 11:49:35PM CET:
On Wed, Jan 04, 2006 at 10:19:27AM +0100, Roger While wrote:
Libtool 1.5.22
There is a problem
option.
It's needed for things like gaim and galculator to work.
--
albert chin ([EMAIL PROTECTED])
___
http://lists.gnu.org/mailman/listinfo/libtool
On Sat, Jun 10, 2006 at 08:29:44PM +0200, Ralf Wildenhues wrote:
* Albert Chin wrote on Sat, Jun 10, 2006 at 08:08:15PM CEST:
Any reason we don't use -bexpall to support -export-dynamic on AIX?
Yes, as commented in libtool.m4:
# It seems that -bexpall does not export symbols beginning
On Sun, Jun 11, 2006 at 01:04:17AM +0200, Ralf Wildenhues wrote:
* Albert Chin wrote on Sat, Jun 10, 2006 at 08:49:29PM CEST:
On Sat, Jun 10, 2006 at 08:29:44PM +0200, Ralf Wildenhues wrote:
* Albert Chin wrote on Sat, Jun 10, 2006 at 08:08:15PM CEST:
Any reason we don't use -bexpall
I missed the addition of $hardcode_direct_absolute for the CXX tag.
2006-05-23 Albert Chin [EMAIL PROTECTED]
* libltdl/m4/libtool.m4 (_LT_LANG_CXX_CONFIG)
[ aix4*, aix5*, hpux10*, hpux11* ]: Forgot to add
hardcode_direct_absolute for CXX tag.
--
albert chin ([EMAIL
=$new_inherited_linker_flags $finalize_deplibs
else
compiler_flags=$compiler_flags $inherited_linker_flags
linker_flags=$linker_flags $inherited_linker_flags
fi
Looking at what is added to $new_inherited_linker_flags in ltmain.sh,
this looks safe.
--
albert chin ([EMAIL
On Thu, May 18, 2006 at 09:53:06AM +0200, Ralf Wildenhues wrote:
* Albert Chin wrote on Thu, May 18, 2006 at 09:40:21AM CEST:
HP-UX 10.20 uses ld rather than cc to create shared libraries. Because
of this, inherited_linker_flags in a *.la file is not added to the
link line.
Which
On Thu, May 18, 2006 at 10:17:42AM +0200, Ralf Wildenhues wrote:
* Albert Chin wrote on Thu, May 18, 2006 at 10:11:29AM CEST:
On Thu, May 18, 2006 at 09:53:06AM +0200, Ralf Wildenhues wrote:
* Albert Chin wrote on Thu, May 18, 2006 at 09:40:21AM CEST:
HP-UX 10.20 uses ld rather than cc
On Wed, May 17, 2006 at 05:17:54PM +0200, Ralf Wildenhues wrote:
* Gary V. Vaughan wrote on Wed, May 17, 2006 at 05:11:46PM CEST:
Ralf Wildenhues wrote:
* Albert Chin wrote on Wed, May 17, 2006 at 03:18:09AM CEST:
The following patch addresses
http://lists.gnu.org/archive/html/libtool
On Wed, May 17, 2006 at 05:59:23PM +0200, Ralf Wildenhues wrote:
* Albert Chin wrote on Wed, May 17, 2006 at 03:18:09AM CEST:
The following patch addresses
http://lists.gnu.org/archive/html/libtool/2006-04/msg00044.html. I
added a new variable, hardcode_direct_static, to indicate
On Wed, May 17, 2006 at 05:00:04PM +0200, Ralf Wildenhues wrote:
* Albert Chin wrote on Wed, May 17, 2006 at 03:18:09AM CEST:
The following patch addresses
http://lists.gnu.org/archive/html/libtool/2006-04/msg00044.html. I
added a new variable, hardcode_direct_static, to indicate
On Wed, May 17, 2006 at 04:48:24PM +0200, Ralf Wildenhues wrote:
* Albert Chin wrote on Wed, May 17, 2006 at 02:44:49PM CEST:
+ case $hardcode_direct$hardcode_direct_static in
+ yesno)
+AT_CHECK([if $EGREP relinking stderr; then
+ $EGREP .*\/new\/lib/libb$shrext_cmds
On Wed, May 17, 2006 at 09:55:42PM +0200, Ralf Wildenhues wrote:
* Albert Chin wrote on Wed, May 17, 2006 at 06:35:06PM CEST:
On Wed, May 17, 2006 at 05:17:54PM +0200, Ralf Wildenhues wrote:
* Gary V. Vaughan wrote on Wed, May 17, 2006 at 05:11:46PM CEST:
Ralf Wildenhues wrote
The following patch addresses
http://lists.gnu.org/archive/html/libtool/2006-04/msg00044.html. I
added a new variable, hardcode_direct_static, to indicate if
hardcode_direct=yes would hardcode a static library dependency. This
impacts HP-UX/PA and AIX.
Patch against HEAD.
2006-05-16 Albert Chin
. Thanks.
--
albert chin ([EMAIL PROTECTED])
___
http://lists.gnu.org/mailman/listinfo/libtool
a a.o
libtool: link: cc -o a a.o
/usr/ccs/bin/ld: Unsatisfied symbols:
main (Not referenced yet! Probably due to -u option)
However, even though there is no main, `a' is still created. How do we
work around this?
--
albert chin ([EMAIL PROTECTED
On Sun, Apr 30, 2006 at 05:09:23PM +0200, Ralf Wildenhues wrote:
* Albert Chin wrote on Sun, Apr 30, 2006 at 05:00:46PM CEST:
I'm getting the following test failure from HEAD on HP-UX 11.23/PA:
However, even though there is no main, `a' is still created. How do we
work around this?
Yes
$hardcode_direct is set twice for AIX.
2006-04-29 Albert Chin-A-Young [EMAIL PROTECTED]
* libltdl/m4/libtool.m4 (_LT_LINKER_SHLIBS) [ aix ]:
$hardcode_direct is set twice.
--
albert chin ([EMAIL PROTECTED])
-- snip snip
Index: libltdl/m4/libtool.m4
On Tue, Apr 25, 2006 at 01:52:00PM -0500, Albert Chin wrote:
[snip snip]
How do we solve this? Either we set hardcode_direct=no for these
platforms or, in ltmain.in, make it smart enough to check and use
hardcode_minus_L=yes before hardcode_direct=yes.
Another possibility is to add a new
/testsuite.dir/14/new/lib/libb.sl
/opt/build/libtool/tests/testsuite.dir/14/old/lib/libcee.sl
But the .* pattern sucks up the
-L/opt/build/libtool/tests/testsuite.dir/14/old/lib.
2006-05-25 Albert Chin-A-Young [EMAIL PROTECTED]
* tests/link-order.at: Take hardcode_direct into consideration
all:
DYLD_LIBRARY_PATH=... LD_LIBRARY_PATH=... SHLIB_PATH=... LIBPATH=... \
python ...
--
albert chin ([EMAIL PROTECTED])
___
http://lists.gnu.org/mailman/listinfo/libtool
:)
http://lists.gnu.org/archive/html/libtool-patches/2004-02/msg00138.html
Good work. Thanks.
--
albert chin ([EMAIL PROTECTED])
On Wed, Feb 01, 2006 at 12:47:51AM -0600, Bob Friesenhahn wrote:
On Tue, 31 Jan 2006, Albert Chin wrote:
On Mon, Jan 30, 2006 at 10:28:52PM +0100, Ralf Wildenhues wrote:
- Should the corresponding libtool flags be named `-Bstatic' resp.
`-Bdynamic'? Those were the most common names I
On Wed, Feb 01, 2006 at 05:40:51PM -0600, Bob Friesenhahn wrote:
On Wed, 1 Feb 2006, Albert Chin wrote:
Fine. -Bstatic on Linux means Do not link against shared libraries.
anyway.
Good. GCC uses -B to mean something else. So -Bstatic is a
linker-only option. It is likely useful to use
-dynamic/-prefer-shared? The -Bxxx doesn't seem
similar with current libtool options.
--
albert chin ([EMAIL PROTECTED])
-dynamic/-prefer-shared? The -Bxxx doesn't seem
similar with current libtool options.
--
albert chin ([EMAIL PROTECTED])
___
http://lists.gnu.org/mailman/listinfo/libtool
`--version' output from this, so it's really needed.
And anyway, we'll likely make changes anyway till the next release;
some other files still needed updates for last year.
Isn't this a question of Copyright law, which easily trounces
--version?
--
albert chin ([EMAIL PROTECTED])
On HEAD, we link with cc rather than ld on HP-UX 11.x. Backport to
1.5. Dunno why I didn't do this long time ago when I submitted the cc
linking patches for Solaris, IRIX, etc.
2005-11-10 Albert Chin-A-Young [EMAIL PROTECTED]
* libtool.m4 (AC_LIBTOOL_PROG_LD_SHLIBS) [ hpux10
When linking C++ libraries/programs, link with the compiler, not the
linker. Syncs with branch-1-5.
--
albert chin ([EMAIL PROTECTED])
-- snip snip
2005-11-09 Albert Chin-A-Young [EMAIL PROTECTED]
* libltdl/m4/libtool.m4 (_LT_LANG_CXX_CONFIG): Sync C++
linking on HP-UX
On Wed, Nov 09, 2005 at 09:51:12PM +0100, Ralf Wildenhues wrote:
* Albert Chin wrote on Wed, Nov 09, 2005 at 05:11:09PM CET:
When linking C++ libraries/programs, link with the compiler, not the
linker. Syncs with branch-1-5.
Erm, I can't see this in branch-1-5.
Oops. My fault. It isn't. I
On Wed, Nov 09, 2005 at 08:23:05PM -0600, Albert Chin wrote:
On Wed, Nov 09, 2005 at 09:51:12PM +0100, Ralf Wildenhues wrote:
* Albert Chin wrote on Wed, Nov 09, 2005 at 05:11:09PM CET:
It's hpux10*|hpux11*, and hppa*64*|ia64*, and aCC|g++, right?
I can vouch for it on hpux11*, hppa*64
On Wed, Nov 09, 2005 at 11:10:26AM -0700, Ed Hartnett wrote:
Albert Chin [EMAIL PROTECTED] writes:
On Tue, Nov 08, 2005 at 06:43:43AM -0700, Ed Hartnett wrote:
Ralf Wildenhues [EMAIL PROTECTED] writes:
The Makefile.am does include:
.f90.o:
$(FCCOMPILE) -c -o
:
$(LTFCCOMPILE) -c -o $@ $(FCFLAGS_f90) $
as you suggested. Unfortunately, that didn't seem to help libtools tag
problem.
If --tag=F77 works, add it to the above.
--
albert chin ([EMAIL PROTECTED])
___
http://lists.gnu.org/mailman/listinfo/libtool
(or have already done so)?
Well, Tim said we do it for other platforms so I say we accept the
patch:
*-*-os2*)
# These systems don't actually have a C library (as such)
test X$arg = X-lc continue
;;
--
albert chin ([EMAIL PROTECTED])
On Fri, Nov 04, 2005 at 05:38:20PM +0100, Ralf Wildenhues wrote:
* Albert Chin wrote on Thu, Nov 03, 2005 at 04:09:03AM CET:
From ld(1) on HP-UX 11.23/IA-64:
+[no]defaultrpath
+defaultrpath is the default. Include any paths
that are specified with -L in the embedded path
only
when there is no +nodefaultrpath (similar to how we set
aix_use_runtimelinking=yes when LDFLAGS has -brtl in it)? We should
probably do this only when the compiler and linker driver are the
same.
--
albert chin ([EMAIL PROTECTED])
___
http
always_export_symbols is set before the if statement enclosing the
code below so remove duplicates.
Patch against branch-1-5.
2005-10-30 Albert Chin-A-Young [EMAIL PROTECTED]
* libtool.m4 (AC_LIBTOOL_LANG_CXX_CONFIG,
AC_LIBTOOL_PROG_LD_SHLIBS): Remove duplicate
On Sun, Oct 30, 2005 at 12:16:01PM -0600, Albert Chin wrote:
On Sun, Oct 30, 2005 at 11:56:30AM -0600, Albert Chin wrote:
On Sun, Oct 30, 2005 at 11:14:14AM -0600, Albert Chin wrote:
[snip ...]
This means the method libtool uses to support -dlopen self on AIX
won't work
On Sun, Oct 30, 2005 at 12:10:23PM -0800, Howard Chu wrote:
Albert Chin wrote:
[snip ...]
Dynamic module support in openldap-2.3.x isn't working on AIX for the
above reason. Using -bexpall or -bE when linking the main binary does
work though. While the main binary, slapd, doesn't dlopen
On Fri, Oct 28, 2005 at 10:05:07AM +0200, Ralf Wildenhues wrote:
* Albert Chin wrote on Thu, Oct 27, 2005 at 11:56:31PM CEST:
On Wed, Oct 26, 2005 at 06:55:11AM -0600, Eric Blake wrote:
- diff vcl.tmp $(srcdir)/stamp-vcl /dev/null \
+ diff vcl.tmp $(srcdir)/stamp-vcl /dev/null 2/dev
in an error.
2005-10-17 Albert Chin-A-Young [EMAIL PROTECTED]
* ltmain.in: When accepting -64, -mips[0-9], et. al. compiler
flags, don't set compiler_flags only for GCC as the vendor
compiler also requires this flag. Sync with HEAD.
Reported by Donald Anderson [EMAIL
, not libtool. Garbage in =
Garbage out.
--
albert chin ([EMAIL PROTECTED])
undefined. As you have the source
to libY, you can find out why the symbol is undefined.
-Original Message-
From: Albert Chin [mailto:[EMAIL PROTECTED]
Sent: Wednesday, October 12, 2005 1:25 PM
To: Nitesh Soni (NC/TNT)
Cc: libtool@gnu.org
Subject: Re: problem linking with shared library
is not using this
symbol at all. How does shared and static libraries treat the
symbols which are undefined.?
When you link against a static library, only those symbols required by
X are linked in.
Thanks
-Original Message-
From: Albert Chin [mailto:[EMAIL PROTECTED]
Sent: Wednesday
On Wed, Sep 14, 2005 at 11:50:05PM -0400, Mike Frysinger wrote:
On Wednesday 14 September 2005 11:36 pm, Albert Chin wrote:
If gcc/ld was used to build the new 'file' program, they would
have the same error as that generated by libtool. Shouldn't
libtool then try to mimic this behavior
as that generated by libtool. Shouldn't libtool then try to
mimic this behavior, not correct it?
Setting LD_LIBRARY_PATH to one of the default search paths is just
wrong anyway.
--
albert chin ([EMAIL PROTECTED])
___
http://lists.gnu.org/mailman/listinfo
in LDFLAGS first.
--
albert chin ([EMAIL PROTECTED])
___
http://lists.gnu.org/mailman/listinfo/libtool
On Tue, Sep 06, 2005 at 07:06:13PM -0700, Marc Singer wrote:
On Tue, Sep 06, 2005 at 08:57:24PM -0500, Albert Chin wrote:
On Tue, Sep 06, 2005 at 04:22:03PM -0700, Marc Singer wrote:
[ snip snip ]
So, the question is this. Do I need to build a special version of
libtool for cross
no clue about *.la files, so is there
some alternative that does?
Why don't we install a pkg-config .pc file for ltdl? That would solve
your problem easily.
--
albert chin ([EMAIL PROTECTED])
___
http://lists.gnu.org/mailman/listinfo/libtool
. The different
variants of this option are for compatibility with various systems.
You may use this option multiple times on the command line: it
affects library searching for -l options which follow it.
--
albert chin ([EMAIL PROTECTED
, is that really the case
or was it just a rumor?
At the moment they are required after a cvs checkout of Libtool HEAD for
building itself.
When will HEAD be able to bootstrap with the latest released
autoconf/automake?
--
albert chin ([EMAIL PROTECTED
is enough - if you have identified
the MS linker, you can use it to list symbols (and I imagine
libtool may need to know about the linker anyway).
If dumpbin is an alias for link with some args, how about scrapping
use of dumpbin and replacing with the appropriate link command-line?
--
albert chin
On Tue, Aug 23, 2005 at 09:53:58AM +0200, Peter Ekberg wrote:
Albert Chin wrote:
Running link /dump has the same effect as running dumpbin; so
perhaps checking for MS Link is enough - if you have identified
the MS linker, you can use it to list symbols (and I imagine
libtool may need
On Tue, Aug 23, 2005 at 08:11:48AM +0200, Ralf Wildenhues wrote:
* Albert Chin wrote on Tue, Aug 23, 2005 at 04:41:58AM CEST:
On Mon, Aug 22, 2005 at 07:54:59PM +0100, Gary V. Vaughan wrote:
Ralf Wildenhues wrote on libtool-patches:
I kept quiet a while ago when Bob first suggested
${libname} | sed -e 's/^lib/cyg/'``echo ${release} |
$SED -e 's/[[.]]/-/g'`${versuffix}${shared_ext}'
;;
--
albert chin ([EMAIL PROTECTED])
___
http://lists.gnu.org/mailman/listinfo/libtool
works with the patch. I say we gamble and ignore
everything below CC v5.4 for this patch.
--
albert chin ([EMAIL PROTECTED])
___
http://lists.gnu.org/mailman/listinfo/libtool
in
it. So, if it's decided that g+s is bad, we could ask the user to
upgrade.
--
albert chin ([EMAIL PROTECTED])
On Tue, Aug 16, 2005 at 12:29:13PM +0100, Gary V. Vaughan wrote:
Ralf Wildenhues wrote:
* Albert Chin wrote on Sat, Aug 13, 2005 at 09:56:43PM CEST:
On Sat, Aug 13, 2005 at 10:40:01AM +0200, Ralf Wildenhues wrote:
2) This looks somewhat ugly in the output, but to a certain extent
.
Way ugly. Just seems to make libtool harder to maintain.
What's the point anyway? To keep function-specific variables from
being clobbered? Was this so much of a problem before libtool had
functions and everything was global? Seems like a solution looking for
a problem.
--
albert chin ([EMAIL
to this myself.
Rather than another switch, how about if --silent is given more than
one, libtool becomes really silent. Kinda like --verbose being given
more than once for some programs being more verbose.
--
albert chin ([EMAIL PROTECTED])
1 - 100 of 272 matches
Mail list logo
