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