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 e
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:
> > >
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, Ralf Wildenhues 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:
> > > >
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
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:
> > > >
x27;ll try to address
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?
--
of libraries is required to get libneon and
> its dependencies. If there's a libtool-aware equivalent macro, it
> would be so much easier.
Is libneon a static library? If not, and libneon has the 3rd-party
libraries as dependencies, w
rough any more effort to use
libtool. Libtool should replace things like AC_CHECK_LIB,
AC_TRY_COMPILE, etc. with invocations to use ./libtool rather than
$CC, $CXX, etc.
--
albert chin ([EMAIL PROTECTED])
___
http://lists.gnu.org/mailman/listinfo/libtool
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 or
UNDEF|backend_group
[43] | 0| 0|FUNC |GLOB |0| UNDEF|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()
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
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_s
phanyS.o | grep language_editor_up_button_clicked_cb
- U language_editor_up_button_clicked_cb
$ nm -BCpg epiphany | grep language_editor_up_button_clicked_cb
269185316 T .language_editor_up_button_clicked_cb
But what I want is the following:
$ nm -BCpg epiphany | grep language_ed
stall the program.
--
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 -dl
, in both cases, libz is not on the command-line used to create the
shared 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 PROTECTED])
___
http://lists.gnu.org/mailman/listinfo/libtool
On Tue, Sep 19, 2006 at 10:11:36AM +0200, Kent Boortz wrote:
>
> Albert Chin <[EMAIL PROTECTED]> writes:
>
> > 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..
mes manipulating the
> underlying tool's input 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
ool documentation for -inst-prefix and DESTDIR.
--
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
s
> bin/info/ lib/man/share/
> %
>
> Disregard that I am using bison as an example. 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
> >
in a .pc file?
Then you have a dependency on libpng and libz, which is unnecessary as
libpng already depends on libz.
I 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
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
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.
-
gt; I delete the /usr/lib/libstdc++.so symlink, I get the error "Could
> not find /usr/lib/libstdc++.so" when linking.
What if you set LDFLAGS="-L/opt/gcc-3.3/lib"?
--
albert chin ([EMAIL PROTECTED])
___
http://lists.gnu.org/mailman/listinfo/libtool
d the correct libraries?
> so on execution libSM and libICE won't be found.
Because /usr/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
d line. 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.
--
alb
> /usr/ccs/bin/ld: Unsatisfied symbols:
>main (Not referenced yet! Probably due to -u option)
While you set CXX=g++, did you set CC=gcc? If not, then the default
bundled compiler, cc, would be selected. 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
When i want to build using 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/bui
ore the object files and libs to be effective
> 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 u
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]
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/class
brary.
But if Sun C++ automatically adds -lm -lc, why, with libtool using C++
to link the library, isn't -lm -lc automatically added? Because Sun C++
is creating a library and not a program?
--
albert chin ([EMAIL PROTECTED])
___
http://lists.gnu.org/mailman/listinfo/libtool
]
$ grep MAINTAINER_MODE_TRUE Makefile.in libltdl/Makefile.in
[nothing]
No problems. What procedure are you using?
This is with Autoconf 2.52 and Automake 1.5.
--
albert chin ([EMAIL PROTECTED])
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
he automake warning/error remains.
I tried to reproduce your warning/error but I could not. The section
of code in automake looks fine to me.
# Ensure a file exists.
sub create
{
my ($file) = @_;
my $touch = new IO::File (">> $file");
$touch->c
results
in:
$ .libs/depdemo
174396:./depdemo: rld: Error: unresolvable symbol in
/opt/build/libtool-1.4.2/tests/_inst/lib/libl4.so.1: var_l3
174396:./depdemo: rld: Fatal Error: this executable has unresolvable
symbols
causing the test to fail. So, is build-relink2.test broken?
--
alb
libtool and autotools it is fine.
Even if you --disable-shared?
--
albert chin ([EMAIL PROTECTED])
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
ctly. You can reach the automake mailing list at
<[EMAIL PROTECTED]>.
--
albert chin ([EMAIL PROTECTED])
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
sac
This seems quite wrong. Why do we assume the compiler will grok -DPIC?
Why isn't this handled in the tag-specific and os-specific portions of
libtool.m4? If the tag/os combo says -KPIC is needed, why do we -KPIC
-DPIC?
--
albert chin ([EMAIL PROTECTED])
___
ention is the test to see if gcj can use
> both -c and -o. This test is failing for some unknown reason, causing
> bad problems for my project. I don't think libtool should even perform
> this test. gcj is known to always handle -c and -o.
What version of gcj are you using?
Why does HEAD libtool use GCJFLAGS when autoconf 2.5x doesn't support
it?
--
albert chin ([EMAIL PROTECTED])
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
f it works. Note this removes
-DPIC completely (even for C, C++).
--
albert chin ([EMAIL PROTECTED])
-- snip snip
Index: libtool.m4
===
RCS file: /cvsroot/libtool/libtool/libtool.m4,v
retrieving revision 1.248
diff -u -3 -p -r1.248 libto
On Fri, Mar 01, 2002 at 12:01:24PM -0700, Tom Tromey wrote:
> >>>>> "Albert" == Albert Chin <[EMAIL PROTECTED]> writes:
>
> Albert> Why does HEAD libtool use GCJFLAGS when autoconf 2.5x doesn't
> Albert> support it?
>
> The support is
nd fail).
You need to be more specific.
1. Does it fail while configuration your application to detect
that static libraries can be built?
2. For what compiler (C, C++, GCJ)?
A snippet of the ./configure run would help too.
--
albe
config.sub from:
ftp://ftp.gnu.org/gnu/config
and rerun ./configure. Let us know if it works.
--
albert chin ([EMAIL PROTECTED])
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
tion.
> eval "`${SED} -n -e '/^# ### BEGIN LIBTOOL TAG CONFIG: '$z'$/,/^# ### END
>LIBTOOL TAG CONFIG: '$z'$/p' < $0`"
> case $base_compile in
> - "$CC "*)
> + "$CC "* | " $CC "* | "`$echo $CC` "* | " `$echo $CC` "*)
> # The compiler in $compile_command matches
> # the one in the tagged configuration.
> # Assume this is the tagged configuration we want.
> - tagname=$z
> - break
> - ;;
> - "`$echo $CC` "*)
> tagname=$z
> break
> ;;
--
albert chin ([EMAIL PROTECTED])
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
he results were,
> we'll get it fixed in both branches eventually.
We routinely build on HP-UX 10.20 and 11.00 with +DAportable. We've
never had a problem. More than likely, the project doesn't pass
$(CFLAGS) to the libtool link command.
--
albert chin ([EMAIL PROTECTED])
___
On Mon, May 27, 2002 at 10:19:53AM +0200, Schleicher Ralph (LLI) wrote:
> Albert Chin <[EMAIL PROTECTED]> writes:
>
> > Hmm, this seems like a positive. Does it have any side affects? Have
> > you made this change and run the test suite against it?
>
> I don'
d like to see 1.4.3. Who else is onboard? What is required to make a
release happen?
--
albert chin ([EMAIL PROTECTED])
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
some patches I'd like to roll in. I'll submit them tomorrow.
How about a test tarball 10/12. That should give others enough time to
get in some patches that might be in the queue.
--
albert chin ([EMAIL PROTECTED])
___
Libtool mailing list
[E
.5x
will be interested in a 1.5 release as it will force them to move to
2.5x. However, for those that don't, I support the 1.4.3 interim
release for those wishing to remain at 2.13 for whatever reason.
If someone is willing to spin the release, I'd like to see us move
ahead with a 1.4.
defined' to `libtool' in
link mode from the package `Makefile'. Naturally, if you pass
`-no-undefined', you must ensure that all the library symbols
*really are* defined at link time!
It seems that CYGWIN needs -no-undefined but this might be problematic
on other unices.
--
albert chin ([EMAIL PROTECTED])
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
t -G isn't added with
> > gcc, but I see it added with xlc_r. By any chance is that something
> > you can confirm or deny?
> >
>
>
> ___
> Libtool mailing list
> [
ot; | sed \
>-e 's:.*FLAGS\}\? :&$lt_compiler_flag :; t' \
>-e 's: [^ ]*conftest\.: $lt_compiler_flag&:; t' \
>-e 's:$: $lt_compiler_flag:'`
Replace 'FLAGS\}\?' with 'FLAGS}?'.
BTW, I don't show a failure on T
o -lc
I've confirmed the above behaviour with a post to the HP-UX Developer
Mailing List. It's frustrating that even though we explicitly list
a/lib1.sl in the link line, it doesn't help.
So, is there anything in libtool to already do this? If not, do we
adopt solution #1 o
On Sat, Dec 14, 2002 at 03:22:42AM -0600, Albert Chin wrote:
> Dependent libraries for hppa64* is funky.
>
> $ cd /tmp/a
> $ ld -b +h lib1.sl.0 -o lib1.sl obj1.o obj2.o -lc
> $ elfdump -L lib1.sl | head
> 0 Needed libc.2
> 1 Soname lib1.sl.0
> $ cd /tmp/b
&
gt; yields:
> $ libtool gcc -o foo c.o -Wl,"-(" A.a B.a -Wl,"-)"
> gcc -o foo c.o -Wl,"-(" -Wl,"-)" A.a B.a
> B.a(b.o): In function `b':
> b.o(.text+0x1b): undefined reference to `a'
> collect2: ld returned 1 exit status
&
ourth hunk) he
> doesn't even know why he's including!
I think some of this was fixed in 1.4.3. Have a peek.
--
albert chin ([EMAIL PROTECTED])
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
libpng.la -lz
-lm
cc +DD64 +O2 +ESlit +Onofltacc +Oentrysched +Odataprefetch +Onolimit
-o .libs/pngtest pngtest.o -L/opt/TWWfsw/zlib11/lib/pa20_64
./.libs/libpng.sl /opt/TWWfsw/zlib11/lib/pa20_64/libz.sl -lm -Wl,+b
-Wl,/opt/TWWfsw/libpng12/lib/pa20_64:/opt/TWWfsw/zlib11/lib/pa20_64
...
--
s used.
> The standard dynamic path search order is LD_LIBRARY_PATH, SHLIB_PATH
> and then the embedded path. The default is for all three to be enabled.
> The enables and search order can be changed with chatr if desired.
I agree that we should use +b to embed the path. Is everyone els
LDFLAGS="-Wl,+b,/path", then
/path won't be in the colon-separated path built by libtool.
Below is the patch against 1.4 with your -L addition.
--
albert chin ([EMAIL PROTECTED])
-- snip snip
Index: libtool.m4
=
png.o
pngerror.o pngget.o pngmem.o pngpread.o pngrio.o pngread.o pngrtran.o
pngrutil.o pngset.o pngtrans.o pngwio.o pngwrite.o pngwtran.o
pngwutil.o -L/opt/TWWfsw/zlib11/lib/pa20_64
-L/opt/TWWfsw/zlib11/lib/pa20_64 /opt/TWWfsw/zlib11/lib/pa20_64/libz.sl
-lm -lc
...
$ elfdump -L .libs/libpng.sl
Yes, I know the 1.4 branch is deprecated.
Because this patch is based on one submitted by Ross Alexander, it
cannot be committed until a copyright assignment form by Ross has been
accepted by the FSF.
2002-12-20 Albert Chin-A-Young ([EMAIL PROTECTED])
* libtool.m4, ltmain.in: Add
L to take a list of tags:
AC_PROG_LIBTOOL([tag1,tag2,...])
Anyone want to submit a patch :)
--
albert chin ([EMAIL PROTECTED])
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
On Mon, Dec 23, 2002 at 09:11:54PM +0100, Sven Hartrumpf wrote:
> I have seen icc support mentioned on the mailing list.
> In which libtool versions is it available?
I think the HEAD branch (1.5).
--
albert chin ([EMAIL PROTECTED])
___
L
On Mon, Dec 23, 2002 at 04:12:46PM -0800, Dan Kegel wrote:
> I discovered to my chagrin that I cannot update
> kaffe from autoconf2.13 to autoconf2.53.
Just update configure in the libltdl directory.
--
albert chin ([EMAIL PROTECTED])
___
L
> Is there some step I'm missing, or something else I'm likely to have
> forgotten to do that is required?
What version of libtool? I think 1.4.3 had some ltdl patches.
--
albert chin ([EMAIL PROTECTED])
___
Libtool mailing list
t;
> Since the last tentative "We'll release in a couple of weeks" (which
> was probably 2 months ago) quite a few platform-related fixes have
> gone into CVS libtool.
What's left to do before 1.5 can be released?
--
albert chin ([EMAIL PROTECTED])
___
atever is
> appropriate for the current compiler and/or linker, when libtool later
> links something with `lib.la'.
I always apply something like the following to gettext. What is of
main interest is the last context diff. The rest is to make it
autoconf 2.5x compatible.
--
alber
On Thu, Jan 02, 2003 at 07:07:42PM -0600, Albert Chin wrote:
> On Thu, Jan 02, 2003 at 06:30:58PM -0600, Tim Mooney wrote:
> > I'm on the libtool list, but not the bug-gnu-gettext list. I haven't
> > looked at this problem long enough to know with any certainty where the
On Thu, Jan 02, 2003 at 10:26:28PM -0600, Tim Mooney wrote:
> In regard to: Re: gettext libintl.la dependency_libs problem, Albert Chin...:
>
> >On Thu, Jan 02, 2003 at 07:07:42PM -0600, Albert Chin wrote:
> >> On Thu, Jan 02, 2003 at 06:30:58PM -0
after the patch is
accepted though.
--
albert chin ([EMAIL PROTECTED])
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
cmds_need_lc, $1)=no
I presume archive_cmds_need_lc=no means that -lc should not be added.
Anyone know more?
--
albert chin ([EMAIL PROTECTED])
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
his
> command line:
>
> icpc -shared -nostdlib .libs/sub1.o -lc -Qoption,ld,-soname \
> -Qoption,ld,libshr.so.0 -o .libs/libshr.so.0.0.0
>
> When I remove -nostdlib and -lc from command line, exe runs without
> problems.
What if you remove only
ile, you'll find the .o files
archived and other .o files (objects of template functions I guess).
Any idea how to properly extract a Sun C++ archive? /usr/bin/ar
wouldn't pull out the extra .o files.
--
albert chin ([EMAIL PROTECTED])
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
If I use ``guile-config'' first, I'll override ``--with-libguile''.
> So much pain. :-(
We solve this by building like so:
$ LDFLAGS="-R[path to guile library]" ./configure
And, in the specific case of guile, we modify guile-config to output
-L[path t
On Mon, Jan 13, 2003 at 10:16:04AM -0800, Bruce Korb wrote:
> Albert Chin wrote:
> >
> > On Sun, Jan 12, 2003 at 04:24:02PM -0800, Bruce Korb wrote
> in http://mail.gnu.org/archive/html/libtool/2003-01/msg00035.html :
> > > ``libguile'' lives in a pl
I got around the problem by modifying
> the libtool script to remove the addition of -DPIC but have no idea if
> this breaks something vitally important (it appeared to work okay).
>
> Steve
--
albert chin ([EMAIL PROTECTED])
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
On Wed, Jan 15, 2003 at 05:23:33PM -0500, Boehne, Robert wrote:
> Good point, we never really resolved this issue.
> All in favor of dropping -DPIC entirely say "I"!
WE :)
> Robert
>
> -Original Message-
> From: Albert Chin [mailto:[EMAIL PROTECTED]]
&
n't give it a blank value and only
test for variables we change, like:
if test "x$_LT_AC_TAGVAR(enable_shared_with_static_runtimes, $1)" != "x"; then
_LT_AC_TAGVAR(enable_shared_with_static_runtimes, $1)=no
fi
--
albert chin ([EMAIL PROTECTED])
__
go::operator<(const Tango::BlackBoxElt&,const
>Tango::BlackBoxElt&)' is multiply-defined:
> (file .libs/tangoSK.o and file .libs/tangoDynSK.o);
>
> Anyone familiar with this?
This isn't a libtool problem. T
On Mon, Jan 20, 2003 at 05:39:50PM +0100, Erik Assum wrote:
> * Albert Chin
> | On Mon, Jan 20, 2003 at 03:27:25PM +0100, Erik Assum wrote:
> | > ld: fatal: symbol `bool Tango::operator==(const Tango::BlackBoxElt&,const
>Tango::BlackBoxElt&)' is multiply-define
g -DPIC for the C and C++ tags? I don't see anything to
gain by choosing a new default or allowing it to be set.
--
albert chin ([EMAIL PROTECTED])
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
e similarly for OSX to support the two-level
namespace (by inspecting CPPFLAGS or CFLAGS or some other variable at
./configure time)? Or do you need a libtool option to do what you
want?
--
albert chin ([EMAIL PROTECTED])
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
Linking the shared library $output against the"
echo "*** static library $deplib is not portable!"
deplibs="$deplib $deplibs"
--
albert chin ([EMAIL PROTECTED])
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
tool 1.4.3. Libtool now searches for the "best" sed in
$PATH on your system.
--
albert chin ([EMAIL PROTECTED])
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
o OSX. However, the only reason I
support this is the impression I get that two-level namespaces are
good for OSX. Is this true? Does Apple *recommend* flat or two-level
namespaces?
--
albert chin ([EMAIL PROTECTED])
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
What date do you plan to release?
--
albert chin ([EMAIL PROTECTED])
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
libppl..0.2.0
>
> It looks like "so" was omitted from "libppl.so" and similarly
> for the other files. This happens on an x86 GNU/Linux system
> (Red Hat 8.0), latest releases of both autoconf and automake.
> Cheers
What version of libtool? Are you using the l
only one type of object file ? My belief is that
> only one type of file should be sufficient.
>
> The main motivation is to reduce the build time
> approximately by a factor of 2 which would be a
> tremendous help for us.
--disable-shared or --disable-static. If you want stati
M="-lm")
>
> and
>
> AC_CHECK_LIB(ltdl, main, ... blah
Gross!
> What is the best path forward?
Replace main with a *real* function in one of the libraries.
--
albert chin ([EMAIL PROTECTED])
___
Libtool mailing list
+ AC_CHECK_LIB(m, cos, LIBM="$LIBM -lm")
Is this too much:
AC_CHECK_FUNC(cos, , AC_CHECK_LIB(m, cos, LIBM="$LIBM -lm"))
We could do the same for:
AC_CHECK_LIB(mw, _mwvalidcheckl, LIBM="-lmw").
--
albert chin ([EMAIL PROTECTED])
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
g string in your update
to doc/libtool.tex:
Please note that you have to
to:
Please note you must
--
albert chin ([EMAIL PROTECTED])
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
o.1
libfontconfig.so.1 -> libfontconfig.so.1.0
libfontconfig.so.1.0
SONAME: libfontconfig.so.1
Can I duplicate this with a libtool-generated libfontconfig shared
library?
--
albert chin ([EMAIL PROTECTED])
___
Libtool mailing list
[EMAIL PROTECTED
The AIX ar/nm commands, by default, don't work with 64-bit object
files. They need the -X64 option added. What's the best way to add
this to libtool? I don't see a quick override for either $AR or $NM.
--
albert chin ([EMAIL PROTECTED])
I have CVS 1.11.5:
$ cvs -d:pserver:[EMAIL PROTECTED]:/var/cvs login
$ cvs -d:pserver:[EMAIL PROTECTED]:/var/cvs co -rbranch-1-5 libtool
cvs [server aborted]: received abort signal
--
albert chin ([EMAIL PROTECTED])
___
Libtool mailing list
101 - 200 of 304 matches
Mail list logo
