]
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
.
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-close;
}
--
albert chin ([EMAIL PROTECTED
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?
--
albert chin ([EMAIL PROTECTED])
-- snip snip
Index: libtool.m4
if you --disable-shared?
--
albert chin ([EMAIL PROTECTED])
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
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])
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
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?
--
albert chin ([EMAIL PROTECTED
(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 libtool.m4
--- libtool.m4 7 Feb 2002 19:54:36 -
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 in automake.
That doesn't help when running autoconf though. Specifically
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.
--
albert chin ([EMAIL PROTECTED])
___
Libtool
. Let us know if it works.
--
albert chin ([EMAIL PROTECTED])
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
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
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
[EMAIL PROTECTED]
http://mail.gnu.org
.
If someone is willing to spin the release, I'd like to see us move
ahead with a 1.4.3.
--
albert chin ([EMAIL PROTECTED])
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
!
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
is that something
you can confirm or deny?
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
--
albert chin ([EMAIL PROTECTED])
___
Libtool mailing list
\}\? :$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 Tru64 UNIX 4.0D nor 5.1. But, I have
some patches on these machines.
--
albert chin ([EMAIL PROTECTED
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 or #2?
--
albert chin ([EMAIL PROTECTED
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
$ ld -b +h lib2.sl.0 -o lib2.sl
+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
...
--
albert chin ([EMAIL PROTECTED])
-- snip snip
Index: libtool.m4
with your -L addition.
--
albert chin ([EMAIL PROTECTED])
-- snip snip
Index: libtool.m4
===
RCS file: /cvsroot/libtool/libtool/libtool.m4,v
retrieving revision 1.166.2.45
diff -u -3 -p -r1.166.2.45 libtool.m4
--- libtool.m4 11 Oct
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
([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])
___
Libtool mailing
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])
___
Libtool
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
[EMAIL PROTECTED]
http://mail.gnu.org/mailman
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 -0600, Tim Mooney wrote:
...
Now say you build
:
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 -lc?
--
albert chin ([EMAIL PROTECTED
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 to guile libraries] *and* -R[path to guile libraries].
--
albert chin ([EMAIL
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 place where LD_LIBRARY_PATH must be set
(viz., /opt/sfw
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]]
Sent: Wednesday, January 15, 2003 4:11 PM
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])
___
Libtool mailing list
[EMAIL
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-defined:
| (file .libs/tangoSK.o
default or allowing it to be set.
--
albert chin ([EMAIL PROTECTED])
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
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
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
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
plan to release?
--
albert chin ([EMAIL PROTECTED])
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
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 static and shared,
you don't have a choice.
--
albert chin ([EMAIL PROTECTED
)
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
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
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]
http
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])
___
Libtool
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
the following libraries by default:
-lCstd -lCrun -lm -lw -lcx -lc
Is it really wise to use -nolib?
--
albert chin ([EMAIL PROTECTED])
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
On Sun, Jun 01, 2003 at 03:47:42PM -0500, Albert Chin wrote:
On Solaris 9/SPARC with:
$ CC -v
CC: Forte Developer 7 C++ 5.4 Patch 111715-06 2003/03/29
...
PASS: tagdemo-conf.test
FAIL: tagdemo-make.test
SKIP: tagdemo-exec.test
PASS: tagdemo-shared.test
FAIL: tagdemo
.
AC_PROVIDE_IFELSE([AC_PROG_CXX],
[AC_LIBTOOL_CXX],
[define([AC_PROG_CXX], defn([AC_PROG_CXX])[AC_LIBTOOL_CXX
])])
Is this suppose to generate the C++ tag *only* if AC_PROG_CXX is
called? If not, what does it mean because the C++ tag is *always*
being created?
--
albert chin ([EMAIL
On Mon, Jun 02, 2003 at 05:06:42PM -0500, Bob Friesenhahn wrote:
On Mon, 2 Jun 2003, Albert Chin wrote:
It's really annoying to have 1.5 automatically generate the C++ and
F77 tags. I'm trying to figure out why it does this. We have the
following in libtool.m4:
dnl If AC_PROG_CXX has
On Tue, Jun 03, 2003 at 01:08:17AM +0200, Alexandre Duret-Lutz wrote:
Albert == Albert Chin [EMAIL PROTECTED] writes:
Albert On Mon, Jun 02, 2003 at 05:06:42PM -0500, Bob Friesenhahn wrote:
On Mon, 2 Jun 2003, Albert Chin wrote:
It's really annoying to have 1.5 automatically
On Tue, Jun 03, 2003 at 08:56:38AM -0500, Bob Friesenhahn wrote:
On Tue, 3 Jun 2003, Alexandre Duret-Lutz wrote:
Albert == Albert Chin [EMAIL PROTECTED] writes:
[...]
Albert I don't have a problem requiring AC_PROG_CXX, AC_PROG_F77, or
Albert AM_PROG_GCJ before AC_PROG_LIBTOOL
On Tue, Jun 03, 2003 at 08:56:38AM -0500, Bob Friesenhahn wrote:
On Tue, 3 Jun 2003, Alexandre Duret-Lutz wrote:
Albert == Albert Chin [EMAIL PROTECTED] writes:
[...]
Albert I don't have a problem requiring AC_PROG_CXX, AC_PROG_F77, or
Albert AM_PROG_GCJ before AC_PROG_LIBTOOL
On Tue, Jun 03, 2003 at 10:58:14AM -0500, Bob Friesenhahn wrote:
On Tue, 3 Jun 2003, Albert Chin wrote:
AC_LIBTOOL_TAGS([c c++])
AC_PROG_LIBTOOL
This means we'd have to get rid of --with-tags. As it's not
documented, I'm for this. If someone specifies AC_LIBTOOL_TAGS, and
say C
])
# Libtool was configured on host `(hostname || uname -n) 2/dev/null | sed 1q`:
@@ -4207,7 +4249,7 @@
ifelse([$1],[],
[# ### END LIBTOOL CONFIG],
-[# ### END LIBTOOL TAG CONFIG: $tagname])
+[# ### END LIBTOOL TAG CONFIG: $1])
__EOF__
--
albert chin ([EMAIL PROTECTED
On Tue, Jun 03, 2003 at 07:43:52PM +0200, Alexandre Duret-Lutz wrote:
Albert Chin [EMAIL PROTECTED] writes:
[...]
| --- libtool.m4.orig 2003-06-01 16:07:41.276467000 -0500
| +++ libtool.m4 2003-06-03 10:22:57.667598339 -0500
[...]
| +AC_PROVIDE_IFELSE([AC_LIBTOOL_TAGS
-06/msg6.html
--
albert chin ([EMAIL PROTECTED])
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
is the current upper limit for the test. Starting with
2**15, you only need three tests to figure out the maximal command line
length, instead of 17. How does that sound?
How do you start out with 2^13 printable characters?
--
albert chin ([EMAIL PROTECTED
} and, if so, add it to deplibs if
hardcode_direct=yes?
--
albert chin ([EMAIL PROTECTED])
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
to your platform.
--
albert chin ([EMAIL PROTECTED])
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
to this
variable.
It should be set in the generated 'libtool' program. Look at
AC_LIBTOOL_SYS_MAX_CMD_LEN in libtool.m4.
Am I supposed to perform additional magic on the ltmain.sh that libtoolize
sticks in my directory?
No.
--
albert chin ([EMAIL PROTECTED
that adds a
new macro, AC_LIBTOOL_TAGS to do what you want. There are some caveats
though.
--
albert chin ([EMAIL PROTECTED])
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
On Sun, Jul 20, 2003 at 07:53:50PM -0700, Keith Packard wrote:
Around 21 o'clock on Jul 20, Albert Chin wrote:
It should be set in the generated 'libtool' program. Look at
AC_LIBTOOL_SYS_MAX_CMD_LEN in libtool.m4.
Yes, it's nicely set in the generated 'libtool' program that gets
is created, this .libs directory is added to
the RPATH entry of program foo. Because program foo is not relinked at
install time, it keeps this RPATH entry.
Looks like we need another variable, inherit_rpath, that relinks
programs when true.
--
albert chin ([EMAIL PROTECTED
On Mon, Jul 21, 2003 at 11:37:27AM -0500, Albert Chin wrote:
Ugh! Looks like IRIX will inherit the RPATH of a library. So, say
program foo is linked against libbar2.so and libbar2.so is dependent
on libbar1.so. At build time, the runtime path of the .libs directory
containing libbar1.so
On Mon, Jul 21, 2003 at 05:02:45PM -0500, Tim Mooney wrote:
In regard to: IRIX inheriting RPATH of libraries, Albert Chin said (at...:
Ugh! Looks like IRIX will inherit the RPATH of a library. So, say
program foo is linked against libbar2.so and libbar2.so is dependent
on libbar1.so
for the upcomming Libtool 1.5 release
but it was silently ignored, too.
Anyone available to review this patch?
--
albert chin ([EMAIL PROTECTED])
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
libpangox.so is created or *after* it is
installed? What matters is the result after installation.
--
albert chin ([EMAIL PROTECTED])
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
but it
doesn't yet.
--
albert chin ([EMAIL PROTECTED])
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
possible solution is to ignore postdeps when creating convenience
libraries.
Any downsides to this? It does seem to make sense. And what about C
convenience libraries (or any convenience library)? Ignore postdeps
totally when creating convenience libraries?
--
albert chin ([EMAIL PROTECTED
If a compiler doesn't support -c -o, libtool creates a lock file by
hard linking the libtool binary with the lock file. This is a problem
if the libtool binary is on a different file system than the lock
file. Why don't we use a symbolic link?
--
albert chin ([EMAIL PROTECTED
On Tue, Aug 26, 2003 at 01:49:10PM +1000, 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
than:
They may be on different fs's.
How is that possible? If we use $srcfile.lock as the lock file
-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]
http://mail.gnu.org/mailman/listinfo/libtool
.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
===
RCS file: /cvsroot/libtool/libtool/ltmain.in
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])
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo
.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-06/msg2.html
Or this one:
http://mail.gnu.org/archive/html/libtool/2003-10/msg00067.html
--
albert chin ([EMAIL PROTECTED
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 PROTECTED
?
--
albert chin ([EMAIL PROTECTED])
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
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_LIBTOOL_TAGS([])
--
albert chin ([EMAIL PROTECTED
++? And, the --enable-shared and --enable-static options would have
to multiply (--enable-c-shared, --enable-cxx-shared, etc).
--
albert chin ([EMAIL PROTECTED])
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
It was mentioned recently on this list.
--
albert chin ([EMAIL PROTECTED])
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
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 looked at
the code) tag inference to work. It doesn't of course.
Before the case, what is the output of:
echo .$CC.
--
albert chin ([EMAIL PROTECTED
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 chin ([EMAIL
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 shared library] ...
| is libtool suppose to pass
++ 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]
http
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])
___
Libtool
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
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
to the package using them?
--
albert chin ([EMAIL PROTECTED])
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
| ${SED} 's%^.*/%%'`
modename=$progname
to:
# The name of this program.
progname=`$echo $0 | ${SED} 's%^.*/%%'`
full_path_progname=$0
modename=$progname
and then we can use $full_path_progname in func_infer_tag().
--
albert chin ([EMAIL PROTECTED
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 $available_tags test -z $tagname
-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-generated for a specific compiler.
--
albert chin ([EMAIL PROTECTED])
___
Libtool
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 ([EMAIL
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])
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
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])
___
Libtool mailing list
[EMAIL PROTECTED]
http
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`\; ...
Does that fix it?
--
albert chin ([EMAIL PROTECTED
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
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't had a chance to look into it. Maybe
this weekend.
--
albert chin ([EMAIL PROTECTED])
___
Libtool
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 12
fi
However, if $absdir has .., and it resolves
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
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
, 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 order?
--
albert chin ([EMAIL PROTECTED])
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org
.
The modules do all load ok under Linux, Solaris, AIX, IRIX, and HP-UX.
Is anyone aware of FreeBSD-specific issues with module loading? Is
there some resource limit that may be expended?
Tried upgrading to the latest 5.x release or 5-CURRENT?
Nothing in sysctl -a stands out to me.
--
albert
1 - 100 of 272 matches
Mail list logo
