IX,
elfdump on IRIX). I don't know how to do this when cross-compiling
though.
--
albert chin ([EMAIL PROTECTED])
___
Libtool mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/libtool
ntrol.
--
albert chin ([EMAIL PROTECTED])
___
Libtool mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/libtool
We shouldn't force the users to change 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&#
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 mail
iler still
> compiles when driven by libtool. If libtool disects options 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
orts
C, C++, GCJ and we should make sure they all accept -D[var]).
--
albert chin ([EMAIL PROTECTED])
___
Libtool mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/libtool
binary must be linked against
this way is fundamentally non-portable. For example, on HP-UX, 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 ([E
Libtool. An an improvement would then be only
> providing the dependency -l flags 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])
_
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.
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])
___
en link.
> [ insert example from Scott ]
So, if we do what you want, libtool behaves different depending on the
platform. Is that really what we want?
--
albert chin ([EMAIL PROTECTED])
___
Libtool mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/libtool
l for other
platforms (Solaris, Linux with non-GCC compilers, IRIX, etc.)? It
seems way too Linux-specific to me.
--
albert chin ([EMAIL PROTECTED])
___
Libtool mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/libtool
to link when $linkmode=prog, library linking is failing with
unresolved symbols (because the dependency libs from dependent .la
files aren't being included in the command-line).
--
albert chin ([EMAIL PROTECTED])
___
Libtool mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/libtool
nt to the compiler, not the linker. Do you mean
-lpthread?
--
albert chin ([EMAIL PROTECTED])
___
http://lists.gnu.org/mailman/listinfo/libtool
On Fri, Dec 10, 2004 at 03:55:14PM -0600, Albert Chin wrote:
> I'm trying to build kde-3.3.1 on AIX 5.2 and because deplibs isn't
> added to link when $linkmode=prog, library linking is failing with
> unresolved symbols (because the dependency libs from dependent .la
> files
der things
> for me?
This is really hard to fix in libtool. It's wrong though.
--
albert chin ([EMAIL PROTECTED])
___
http://lists.gnu.org/mailman/listinfo/libtool
r, trying to
> dlopen more than one such DSO 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
OR 4: Conflicting flag setting: -exports_file
> ld32: ERROR 4: Conflicting flag setting: -exports_file
> collect2: ld returned 2 exit status
Please rerun with -v so we see who gcc is calling.
--
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
On Fri, Jan 14, 2005 at 09:28:54PM +0100, Peter Ekberg wrote:
> Albert Chin wrote:
> > 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
h=pwr3 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
do needless
rework the next time it is invoked. To work around this problem,
you can use a timestamp file, e.g.:
dest-stamp: src
cp -p src dest
date >dest-stamp
I don't see any signs in it of `cp -p' being non-portable.
--
albert chin ([EMAIL PROTECTED])
___
http://lists.gnu.org/mailman/listinfo/libtool
onv19/lib
-L/usr/openwin/lib -R/usr/openwin/lib -L/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/libM
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 th
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 PROTECTED])
___
http://lists.gnu.org/mailman/listinfo/libtool
if I 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?
lax/libknotesconfig.a/knoteconfig.o
.libs/knotes_local.lax/libknotesconfig.a/knotesglobalconfig.o
C++ prelinker: error: file
".libs/knotes_local.lax/libknotesconfig.a/ii_files/knoteconfig.ii" is
read-only
--
albert chin ([EMAIL PROTECTED])
___
http:/
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
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 co
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 ob
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
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:
> > On Fri, Mar 04, 2005 at 10:19:02AM +0900, Peter O'Gorman wrote:
> > > Albert Chin wrote:
> > > | On Thu, Mar 03, 2005 at 01:
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:
> > >
> not using the compiler to automatically link in any libraries. 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
libtool bug never die?
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
http://gcc.gnu.org/ml/gcc/2005-05/msg00031.html
--
albert chin ([EMAIL PROTECTED])
___
http://lists.gnu.org/mailman/listinfo/libtool
; && test -n '\''$striplib'\''; then
eval '\''$striplib \$dldir/$dlname'\'' || exit \$?;
fi'
postuninstall_cmds='dldll=`$SHELL 2>&1 -c '\''. $file; e
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
= 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])
___
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&
for removing *\)* from the
case statement.
--
albert chin ([EMAIL PROTECTED])
___
http://lists.gnu.org/mailman/listinfo/libtool
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
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:
> > >
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
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
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
> 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
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
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
LIB_PATH for
the in-build-directory binary to work?
--
albert chin ([EMAIL PROTECTED])
___
http://lists.gnu.org/mailman/listinfo/libtool
-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
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
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
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
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
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
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
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
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
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
iled libs]" and
libtool should look 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
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 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
&
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.
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
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
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
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
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:
. 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-
>
because they
weren't exported.
--
albert chin ([EMAIL PROTECTED])
___
http://lists.gnu.org/mailman/listinfo/libtool
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 -
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: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 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 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
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 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
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 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
> 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
'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
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
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 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
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
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
/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
>
> 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])
___
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
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 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
should we need it
> elsewhere.)
It works fine. Thanks.
--
albert chin ([EMAIL PROTECTED])
___
http://lists.gnu.org/mailman/listinfo/libtool
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
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
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:
> > > &
noentry
option.
It's needed for things like gaim and galculator to work.
--
albert chin ([EMAIL PROTECTED])
___
http://lists.gnu.org/mailman/listinfo/libtool
1 - 100 of 304 matches
Mail list logo
