nd hardlinks for that matter, is portability.
> Not all systems support them.
We only need to worry about it on systems without -c -o support.
--
albert chin ([EMAIL PROTECTED])
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
On Tue, Aug 26, 2003 at 10:56:47AM -0500, Bob Friesenhahn wrote:
> On Tue, 26 Aug 2003, Robert Collins wrote:
>
> > On Tue, 2003-08-26 at 12:58, Albert Chin wrote:
> >
> >
> > > Why not use $srcfile and "$srcfile.lock" as the lock file? So, rather
> &
> mymod_la_LDFLAGS = -module -avoid-version
>
> This also removes the requirement that the library name start with "lib."
This depends on the platform.
--
albert chin ([EMAIL PROTECTED])
___
Libtool mailing list
[EMAIL PROTECTED]
lib
What happens if you move /usr/lib/libxml2* out of the way first? Does
it then find /dstc/lib/libxml2.la. If so, looks like a libtool bug.
--
albert chin ([EMAIL PROTECTED])
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
gdbm.la -L/dstc/lib /usr/lib/libxml2.la -lz -lpthread
> -lm -ldb'
>
> How did that /usr/lib/libxml2.la get in there?
Does this fix it (should apply to 1.5)?
--
albert chin ([EMAIL PROTECTED])
-- snip snip
Index: ltmain.in
/src/verbiste
> /usr/lib/libverbiste-0.1.so
Does this patch (against 1.5) work for you?
http://mail.gnu.org/archive/html/libtool/2003-10/msg00067.html
It should be trivial to apply the patch to your 1.4.3 version.
--
albert chin ([EMAIL PROTECTED])
___
>version is 1.5.0a. I've been looking around for references to
> >/usr/lib/libfreetype in the local .la files, but with no luck.
> >
> >Any ideas on how to proceed from here?
>
> Does this patch from Ben Reed help?
> http://mail.gnu.org/archive/html/libtool-patches/2003-
If I invoke libtool as so:
$ libtool ... [path to shared library] ...
is libtool suppose to pass [path to shared library] to the final link
stage? It's ignoring anything on the command line that ends with
*$shrext.
--
albert chin ([EMAIL PROT
btool: invalid number of arguments
What if you replace "gcc\ " with "gcc "?
--
albert chin ([EMAIL PROTECTED])
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
even if the CXX/GCJ/F77/RC tags are never used; my solution
> has been to redefine AC_LIBTOOL_CXX_CONFIG and friends to a colon, but this
> is quite of a hack. Again I ask if there is a nicer way to strip down my
> already huge (750kb) configure script.
Does this help?
AC_
odd that you create shared libs for "C" programs and static for
"C++"? And, the --enable-shared and --enable-static options would have
to multiply (--enable-c-shared, --enable-cxx-shared, etc).
--
albert chin ([EMAIL PROTECTED])
___
about -R. However, you might find this useful:
http://mail.gnu.org/archive/html/autoconf/2002-05/msg00124.html
It was mentioned recently on this list.
--
albert chin ([EMAIL PROTECTED])
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
sed: not found
Looks like $echo is NULL.
> + $Xsed -e $sed_quote_subst`\
> config.status[527]: $Xsed: not found
> + eval lt_SHELL=\`$echo X$SHELL
> + X/bin/sh
> + lt_SHELL=`print -r
> config.status[527]: X/bin/sh: not found
Ditto.
> + $Xsed -e $sed_quote_subst`\
&g
gram name with arguments (isn't it?), but
> at this point $base_compile only contains the program name "gcc" in my
> case, so when I set CC to (on darwin) "gcc -arch ppc -arch i386" and set
> CXX to "g++ -arch ppc -arch i386" I expected (without having look
Repost as the first try didn't garner a response.
If I invoke libtool as so:
$ libtool ... [path to shared library] ...
is libtool suppose to pass [path to shared library] to the final link
stage? It's ignoring anything on the command line that ends with
*$shrext.
--
albert ch
On Tue, Dec 16, 2003 at 11:33:15AM +, Gary V. Vaughan wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Albert Chin wrote:
> | Repost as the first try didn't garner a response.
> |
> | If I invoke libtool as so:
> | $ libtool ... [path to share
dor C++ compiler. Do we need to do something similar? Or is it
easier for us to say that if $LD == $CC for a tag, any unrecognized
options are passed to $compiler_flags?
--
albert chin ([EMAIL PROTECTED])
___
Libtool mailing list
[EMAIL PROTECTED]
g for building 64-bit C++ libraries with the
vendor C++ compiler. Do we need to do something similar? Or is it
easier for us to say that if $LD == $CC for a tag, any unrecognized
options are passed to $compiler_flags?
--
albert chin ([EMAIL PROTECTED])
___
Li
Why does win32_libid() in ltmain.in use "grep -E" rather than $EGREP?
--
albert chin ([EMAIL PROTECTED])
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
plies that they need to
> come on the link line before libXm.dylib. They do.
Shouldn't the libraries in dependency_libs come after the library? Or
am I missing something?
--
albert chin ([EMAIL PROTECTED])
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
verbatim).
Ugh. So *every* package providing useful 3rd-party autoconf macros
must be copied locally to the package using them?
--
albert chin ([EMAIL PROTECTED])
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
dify the top of ltmain.in from:
# The name of this program.
progname=`$echo "$0" | ${SED} 's%^.*/%%'`
modename="$progname"
to:
# The name of this program.
progname=`$echo "$0" | ${SED} 's%^.*/%%'`
full_path_progname=&q
On Wed, Feb 11, 2004 at 07:02:00PM +, Gary V. Vaughan wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Albert Chin wrote:
> | So this means func_infer_tag() is broken in branch-1-5 because it does
> | this:
> | func_infer_tag () {
> | if test -n &
e/john
> /common/gpslib/source/build/output/sol/objs/.libs/slsmath.o -L/home/john/
> common/gpslib/source/build/output/sol/lib -L/lib -lc
You cannot use a libtool configured for GCC with the Sun compiler.
Each "libtool" script is custom-g
On Fri, Feb 13, 2004 at 10:52:02AM -0800, johnny henrik wrote:
> How do I configure libtool to work with CC compiler?
> Please give my some pointer/link ...
Build it just like you did to create /usr/local/bin/libtool but use
The Sun C compiler (i.e. CC=cc CFLAGS=blah).
--
albert chin (
bdir taking ".."
into consideration, the warning is still printed. How do we solve
this? (cd $absdir; /bin/pwd) won't work because of automounter
madness.
Or should we just remove the message?
--
albert chin ([EMAIL PROTECTED])
___
Lib
ed libraries need
> to be told where to look at runtime. LDFLAGS looks like this:
>
> -L/usr/local/lib -Wl,-rpath /usr/local/lib
You should use -Wl,-rpath,/usr/local/lib
^
--
albert chin ([EMAIL PROTECTED])
___
Libtoo
generate a line which looks like the following:
>
> relink_command="(cd /home/michael/my code/src; ...)"
Search your "libtool" script for a line like:
relink_command="(cd `pwd`; ...
and change it to:
relink_command="(cd \"`pwd`\&quo
re info. I think if you have VERBOSE=1
set the tests will be more verbose.
--
albert chin ([EMAIL PROTECTED])
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
g passed to ld, and ld doesn't understand
> that option.
>
> I haven't had a chance to look much at the problem, but thought I would
> report it. Please let me know if I can provide additional information.
I noticed this too but haven&#
On Fri, Feb 13, 2004 at 02:07:12PM -0600, Albert Chin wrote:
> ltmain.in prints out a warning when it thinks the .la file isn't in
> $libdir:
> if test "$absdir" != "$libdir"; then
> $echo "$modename: warning: \`$deplib' seems to be moved"
to *.la files.
I don't think libtool is doing this. It looks like it's preferring
libraries with corresponding .la files. Even that is a bug though.
Someone needs to dig further.
--
albert chin ([EMAIL PROTECTED])
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
s is all done automatically by lt_dlopen. If it
> isn't then it should be...
Yes, it should be. BTW, how do we handle the case where
need_lib_prefix!=no?
--
albert chin ([EMAIL PROTECTED])
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
ding of the library dependencies when libraries are
> built using a recursive build. Without understanding the library
> dependencies, it is difficult to see how relinking would work.
Why not just have the developer write a Makefile.am so the libraries
are built/installed in the correct orde
tml
http://mail.gnu.org/archive/html/libtool-patches/2004-02/msg00131.html
http://mail.gnu.org/archive/html/libtool-patches/2004-03/msg00018.html
--
albert chin ([EMAIL PROTECTED])
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
On Sun, Mar 14, 2004 at 06:32:04PM +, Scott James Remnant wrote:
> On Sun, 2004-03-14 at 17:47, Albert Chin wrote:
>
> > On Sun, Mar 14, 2004 at 03:00:27PM +, Scott James Remnant wrote:
> > > On Sun, 2004-03-14 at 14:51, Peter O'Gorman wrote:
> > >
&
T?
Nothing in sysctl -a stands out to me.
--
albert chin ([EMAIL PROTECTED])
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
p4.so has pthread_*
symbols but no libpthread/libthread as a result of the above.
--
albert chin ([EMAIL PROTECTED])
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
d for C. When linking using the linker, the library dependencies
> >are more assured, but we loose all the platform smarts which are
> >included for free with the compiler.
>
> My thoughts exactly. If no-one beats me to it, I'll try and look at
> this next week.
I alre
On Tue, Apr 13, 2004 at 10:42:05PM +0100, Gary V.Vaughan wrote:
> On 14 Apr 2004, at 18:55, Albert Chin wrote:
>
> >I already have it done for Solaris, HP-UX, Tru64 UNIX, and IRIX. My
> >patch is for the 1.5 branch. I'll forward-port to the 1.6 branch and
> >post t
ibtool solve this? Without
libtool, the developer should be using the C++ compiler to link
anyway.
--
albert chin ([EMAIL PROTECTED])
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
On Thu, Apr 15, 2004 at 02:43:57PM -0500, Bob Friesenhahn wrote:
> On Fri, 16 Apr 2004, Albert Chin wrote:
>
> > On Thu, Apr 15, 2004 at 11:10:20AM -0500, Bob Friesenhahn wrote:
> > > If a program which is based on C language depends on a library which
> > >
sl13/lib/sparcv9 Solaris 64-bit
We do the same for binaries (in the case of LSOF, you need both 32 and
64-bit depending on the kernel you run for some platforms) and
possibly include files, if the include files are specific to the
compiler.
--
albert chin ([EMAIL PROTECTED])
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
I'm in favor of keeping things simple as they are now.
--
albert chin ([EMAIL PROTECTED])
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
esen/src/gnu/gcc-3.4.0-build/sparc-sun-solaris2.9/libstdc++-v3/src/.libs
> -L/home/bfriesen/src/gnu/gcc-3.4.0-build/gcc
What does dependency_libs in libstdc++.la look like?
--
albert chin ([EMAIL PROTECTED])
___
Libtool mailing list
[EMAIL PROTEC
On Sun, May 02, 2004 at 06:24:50PM -0500, Bob Friesenhahn wrote:
> On Sun, 2 May 2004, Albert Chin wrote:
>
> > On Sun, May 02, 2004 at 01:47:09PM -0500, Bob Friesenhahn wrote:
> > > I am encountering a problem with gcc 3.4.0 in that when libtool
> > > performs a C+
ttp://lists.kde.org/?l=kde-core-devel&m=108534182408921&w=2
dependency_libs doesn't contain just libraries. Maybe LDFLAGS as well,
like -pthread. BTW, is it _really_ a problem to link against
everything in dependency_libs? Indirectly, this is going to happen
anyway even if libtool
On Mon, May 24, 2004 at 07:32:01PM -0500, Bob Friesenhahn wrote:
> On Mon, 24 May 2004, Albert Chin wrote:
>
> >On Mon, May 24, 2004 at 08:19:00AM +0200, Szombathelyi Gy?rgy wrote:
> >>I've just curious if is it possible _not_ to link a program/lib against
> >>i
On Tue, May 25, 2004 at 11:37:38AM +0200, Szombathelyi_GyXrgy wrote:
> >On Mon, 24 May 2004, Albert Chin wrote:
> >
> >>dependency_libs doesn't contain just libraries. Maybe LDFLAGS as well,
> >>like -pthread. BTW, is it _really_ a problem to link agains
o buy you much on the platforms you're interested
in.
--
albert chin ([EMAIL PROTECTED])
___
Libtool mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/libtool
On Sat, Jun 05, 2004 at 09:54:03PM +0200, Stephane Bortzmeyer wrote:
> On Wed, Jun 02, 2004 at 12:51:31PM -0500,
> Albert Chin <[EMAIL PROTECTED]> wrote
> a message of 21 lines which said:
>
> > Does this work:
> > AC_SEARCH_LIBS(dlopen, [-ldl])
> >
>
(-export-symbols-regex using libtool).
> As you can note from output above first it try to compute symbols to
> export (using grep) however it cannot find symbol file cause it's
> created after grep (using nm).
On HP-UX, you _cannot_ create a shared libraries with .o files built
w
t;-tag" option (note one `-').
--
albert chin ([EMAIL PROTECTED])
___
Libtool mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/libtool
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
the hopes that one of them must work:
% CC -WpKfbal,-LANG:std std.cc
ld32: ERROR 33 : Unresolved text symbol
"std::ios_base::_S_initialize(void)" -- 1st referenced by std.o.
Use linker option -v to see when and which objects, archives
and dsos are loaded.
...
So, I do not thin
On Wed, May 03, 2000 at 02:20:51AM -0300, Alexandre Oliva wrote:
> On May 3, 2000, Albert Chin-A-Young <[EMAIL PROTECTED]> wrote:
>
> > On Tue, May 02, 2000 at 11:10:32PM +0100, Gary V. Vaughan wrote:
> >> On Sat, Apr 22, 2000 at 09:53:42AM -0500, Bob Friesenhahn wro
On Wed, May 03, 2000 at 02:36:52AM -0300, Alexandre Oliva wrote:
> On May 3, 2000, Albert Chin-A-Young <[EMAIL PROTECTED]> wrote:
>
> > Ok, thanks. However, this raises another problem.
> > CXXFLAGS="-Wc,-LANG:std" won't work as the configure te
On Wed, May 03, 2000 at 12:48:30AM -0500, Albert Chin-A-Young wrote:
> On Wed, May 03, 2000 at 02:36:52AM -0300, Alexandre Oliva wrote:
> > On May 3, 2000, Albert Chin-A-Young <[EMAIL PROTECTED]> wrote:
> >
> > > Ok, thanks. However, this raises another problem.
*)
> case $host/$arg in
> *-*-irix*/-L[A-Z][A-Z]*:*) continue ;;
> esac
>
> ...
> ;;
You cannot just 'continue'. You need something like:
case "$host/$arg" in
*-*-irix*/-LANG:*)
compile_command="$compile_command $arg"
continue
;;
esac
I've tested just 'continue' and --mode=link doesn't pass -LANG:std
through.
--
albert chin ([EMAIL PROTECTED])
ld it be worthwhile to cache already-dlopen'ed
libraries? If so, what would happen if one of the dlopen'ed libraries
got updated while the program was running? Because we cached the fact
that the library was already loaded, the library would not be reloaded
(though I suppose we could use a sta
On Sat, Oct 21, 2000 at 03:03:13PM -0500, Albert Chin-A-Young wrote:
> On Fri, Oct 20, 2000 at 03:22:38PM +0200, Matthias Koeppe wrote:
> > While trying to use the new interlibrary dependency resolution
> > (load_deplibs) in the CVS version of libtool, we found out that it is
>
/lib/libpng.a", O_RDONLY) Err#2 ENOENT
open("/opt/libpng/lib/libpng.so", O_RDONLY) = 3
open("/usr/lib/libz.so.2", O_RDONLY)Err#2 ENOENT
open("/opt/libpng/lib/libpng.so", O_RDONLY) = 3
open("/usr/lib/libz.so.2", O_RDONLY)Err#2 ENOENT
--
albert chin ([EMAIL PROTECTED])
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
thing i have here.
Please post what you have found to the list.
--
albert chin ([EMAIL PROTECTED])
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
if (strncmp(line, STR_DL_DEPLIBS,
> sizeof(STR_DL_DEPLIBS) - 1) == 0)
> error = trim(&deplibs,
>
> --
> Matthias Köppe -- http://www.math.uni-magdeburg.de/~mkoeppe
--
albert chin ([EMAIL PROTECTED])
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
Compaq Tru64 UNIX 5.0.
The failure above is on Solaris 2.5.1-8/SPARC.
Is it possible to tell Solaris to try and resolve all symbols before
trying to load in dependent libraries? If not, what advantages does
ltdl bring to the table on Solaris for automatically loading in
dependency libraries? I
o the run-time linker will be able
> > to find all libs and resolve all symbols. Solaris' run-time
> > linker only uses the RPATH found in libpng.so to find libs,
> > that png depends on. IRIX and True64 use a globalized RPATH
> > in the executable binary for all library searches, which is
> > wrong.
> >
> > Bjoern
> >
> >
>
>
> ___
> Libtool mailing list
> [EMAIL PROTECTED]
> http://mail.gnu.org/mailman/listinfo/libtool
--
albert chin ([EMAIL PROTECTED])
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
On Wed, Dec 20, 2000 at 01:54:04PM -0600, Albert Chin-A-Young wrote:
> On Wed, Dec 20, 2000 at 02:01:17PM -0500, Tom Kacvinsky wrote:
> > Huh? My experience (on Solaris) has been that if foo.so has an
> > embedded RPATH and the application bar uses foo.so and also has a
>
sions have no or bad support for hardcoding RPATHs
> into shared objects.
Not all systems allow you to embed RPATH in a library. Tru64 UNIX 4.0D
is one. I think libtool 1.4 and above allow you to embed RPATH.
--
albert chin ([EMAIL PROTECTED])
__
201 - 300 of 304 matches
Mail list logo
