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
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
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]
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
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
> /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
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
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
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
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.
-
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
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 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
> >
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 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
ool documentation for -inst-prefix and DESTDIR.
--
albert chin ([EMAIL PROTECTED])
___
http://lists.gnu.org/mailman/listinfo/libtool
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
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..
, 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 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
stall the program.
--
albert chin ([EMAIL PROTECTED])
___
http://lists.gnu.org/mailman/listinfo/libtool
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
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
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 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()
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 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
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
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
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?
--
x27;ll try to address
this soon.
--
albert chin ([EMAIL PROTECTED])
___
http://lists.gnu.org/mailman/listinfo/libtool
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 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 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 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 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 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
noentry
option.
It's needed for things like gaim and galculator to work.
--
albert chin ([EMAIL PROTECTED])
___
http://lists.gnu.org/mailman/listinfo/libtool
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:
> > > &
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 th
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 PROTECTED])
___
http://lists.gnu.org/mailman/listinfo/libtool
should we need it
> elsewhere.)
It works fine. Thanks.
--
albert chin ([EMAIL PROTECTED])
___
http://lists.gnu.org/mailman/listinfo/libtool
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. Ho
sh /opt/build/libtool/libtool --mode=link cc -o 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 a
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 possibil
>
> My question are :
>
> - Why it's not possible to mix libraries on HP-UX ?
> - Is there a way to resolve this situation ?
We solved this by modifying the imap makefile to build the c-client
library using libtool.
--
albert chin ([EMAIL PROTECTED])
___
/usr/lib/libm.2
/opt/TWWfsw/zlib11/lib/libz.sl.2 => /tmp/libz.sl.2
/usr/lib/libc.2 => /usr/lib/libc.2
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 hardco
have another look
> there.)
Set them all:
DYLD_LIBRARY_PATH=... LD_LIBRARY_PATH=... SHLIB_PATH=... LIBPATH=... \
python ...
--
albert chin ([EMAIL PROTECTED])
___
http://lists.gnu.org/mailman/listinfo/libtool
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
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.
> >> `-Bdy
em.
-prefer-static, -prefer-dynamic/-prefer-shared? The -Bxxx doesn't seem
similar with current libtool options.
--
albert chin ([EMAIL PROTECTED])
___
http://lists.gnu.org/mailman/listinfo/libtool
On Thu, Jan 05, 2006 at 02:03:49PM +0100, Ralf Wildenhues wrote:
> * Albert Chin wrote on Wed, Jan 04, 2006 at 11:49:35PM CET:
> > We can ditch hardcode_libdir_flag_spec_ld for HP-UX.
>
> In the C++ case, yes, but for some HP-UX cases we use $LD still.
> Wouldn't a bette
't like that !
We can ditch hardcode_libdir_flag_spec_ld for HP-UX.
--
albert chin ([EMAIL PROTECTED])
___
http://lists.gnu.org/mailman/listinfo/libtool
> macros mentioned above? Where is the definite source for config.rpath?
> From searches on the web it is not clear to me which project is
> responsible for all this (libtool, autoconf, gettext, ?).
config.rpath is from the GNU gettext
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:
>
> >> Th
de:
>
> .f90.o:
> $(FCCOMPILE) -c -o $@ $(AM_FCFLAGS) $(FCFLAGS_f90) $<
>
> .f90.obj:
> $(FCCOMPILE) -c -o $@ $(AM_FCFLAGS) $(FCFLAGS_f90)
> `$(CYGPATH_W) '$<'`
>
> .f90.lo:
> $(LT
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
> >tha
yes 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])
___
h
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
> >wor
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 sup
On Sun, Oct 30, 2005 at 11:38:26AM -0800, Howard Chu wrote:
> 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 w
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 (by building a list of symbols into
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 (by building a list of symbols into some xxS.o file and
> linking it with the executable). The real solution is to -
because they
weren't exported.
--
albert chin ([EMAIL PROTECTED])
___
http://lists.gnu.org/mailman/listinfo/libtool
. Also, point to be noted is X 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-
>
om
libY.a to determine which one has Z 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:
se versions have symbol Z as "U"
Is symbol Z defined in executable X?
What specific error is the linker giving?
What platform?
--
albert chin ([EMAIL PROTECTED])
___
http://lists.gnu.org/mailman/listinfo/libtool
nstead, I believe.
>
> I did notice that LTLIBINTL was correct (i.e. used -L/local/gnu/lib -lintl
> instead of /local/gnu/lib/libintl.so) but that's not what aspell was
> using (it's using LIBINTL).
Seems like an easier fix to use LTLIBINTL than my patch :) Tim, want
to s
e)
> Untested due to time constraints, sorry.
Seems so. I think we came up with the patch when building KDE. We
never use the stock libtool so the above doesn't matter for us. I
didn't have time to further refine and test the patch so I never
submitted it.
--
albert chin ([EMAIL PROTECTED])
___
http://lists.gnu.org/mailman/listinfo/libtool
ed
> by path. I assumed that the AM_GNU_GETTEXT was doing that for a reason.
I think it's doing it because of the macros in lib-link.m4 (from the
gettext distribution).
--
albert chin ([EMAIL PROTECTED])
___
http://lists.gnu.org/mailman/listinfo/libtool
so I can
> understand why it's doing that.
Does the below fix it for you?
--
albert chin ([EMAIL PROTECTED])
-- snip snip
Index: ltmain.in
===
RCS file: /cvsroot/libtool/libtool/Attic/ltmain.in,v
retrieving revision 1.334.2.
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
&
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, not "correct" it?
Setting LD_LIBRARY_PATH to one of the default search paths is just
wrong anyway.
--
albert chin ([EMAIL PROT
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
iled libs]" and
libtool should look in LDFLAGS first.
--
albert chin ([EMAIL PROTECTED])
___
http://lists.gnu.org/mailman/listinfo/libtool
BS to include
> whatever is necessary?
>
> is there something that works like AC_CHECK_LIB, except that
> AC_CHECK_LIB seems to have 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 prob
on
platforms for which shared libraries are supported. 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 wh
red, at least at some point, 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/au
ext_cmds so we don't have to do things like:
case $host_os in
cygwin*)
# Cygwin DLLs use 'cyg' prefix rather than 'lib'
soname_spec='`echo ${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
On Tue, Aug 23, 2005 at 03:03:20PM +0100, Gary V. Vaughan wrote:
> Albert Chin wrote:
> >On Tue, Aug 23, 2005 at 08:11:48AM +0200, Ralf Wildenhues wrote:
> >
> >>So my point is: get HEAD stable now, then branch off and make
> >>2.59/1.9.6 compatible there. Th
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 qu
Unfortunately, we don't have CC v5.4 to test against. However,
everything about 5.5 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
nf-2.59 and automake-1.9.2.
I'm not against requiring the latest, as of now, autoconf/automake,
but relying on autoconf-2.60 and automake-1.10 seems way too
aggressive.
--
albert chin ([EMAIL PROTECTED])
___
http://lists.gnu.org/mailman/listinfo/libtool
know how they do it.
I thought of the convenience library solution as well. I don't 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 d
-lsocket -lnsl -o 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 ...
--
al
LIB_PATH for
the in-build-directory binary to work?
--
albert chin ([EMAIL PROTECTED])
___
http://lists.gnu.org/mailman/listinfo/libtool
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: Fun
gt; > echo Xbla | sed 1s,^X,,
> >work there? (Libtool currently does not quote this consistently.)
>
> I 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
> generate the libraries, libtool embeds the library SONAME with the major
> version into the library by default.
But libtool does not compute the SONAME across all platforms the same.
--
albert chin ([EMAIL PROTECTED])
___
http://lists.gnu.org/mailman/listinfo/libtool
7;t a directory, then it's interpreted as a "loader 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 PROTE
00 Feb 7 2003 /bin/ksh
3380 -rwxr-xr-x 2 bin bin 274400 Feb 7 2003 /usr/bin/posix/sh
--
albert chin ([EMAIL PROTECTED])
___
http://lists.gnu.org/mailman/listinfo/libtool
gt; make all-am
> /bin/ksh ./libtool --tag=CC --mode=compile cc -DHAVE_CONFIG_H -I. -I. -I.
> -g -c -o ltdl.lo ltdl.c
> 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
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:
> > >
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 c
for removing *\)* from the
case statement.
--
albert chin ([EMAIL PROTECTED])
___
http://lists.gnu.org/mailman/listinfo/libtool
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&
= 0; }' < /etc/ld.so.conf | $SED -e
'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])
___
versioning scheme is very 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
; && test -n '\''$striplib'\''; then
eval '\''$striplib \$dldir/$dlname'\'' || exit \$?;
fi'
postuninstall_cmds='dldll=`$SHELL 2>&1 -c '\''. $file; e
http://gcc.gnu.org/ml/gcc/2005-05/msg00031.html
--
albert chin ([EMAIL PROTECTED])
___
http://lists.gnu.org/mailman/listinfo/libtool
1 - 100 of 304 matches
Mail list logo
