Scott James Remnant [EMAIL PROTECTED] writes:
ftp://ftp.gnu.org/gnu/libtool/libtool-1.5-1.5.2.diff.gz
This doesn't seem to have the changes to the generated files,
therefore requiring a re-autoconf etc. I think a diff is normally
meant to be between the .tar files of the respective versions.
Peter Eisentraut [EMAIL PROTECTED] writes:
Shouldn't that be
AC_ARG_WITH([included-ltdl],
^
No, it's the name of a variable.
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
Peter Eisentraut [EMAIL PROTECTED] writes:
The first argument of AC_ARG_WITH is the (partial) name of a
command-line option, not a variable.
Oops, yep, its munged automatically for the variable.
___
Libtool mailing list
[EMAIL PROTECTED]
Martin Frydl [EMAIL PROTECTED] writes:
- config.guess does not use CFLAGS when making compilation checks but
this can be fixed by providing necessary flags directly in CC
variable
I think the cpu type guessed is supposed to depend only on the system,
not on an intended compiler mode. (Though
Thomas Maier [EMAIL PROTECTED] writes:
if linux's behaviour is really extraordinary or if systems
with such limited library features are slowly dying away?
Making just one pass across a -lfoo library at its point in the
command line is traditional unix style, for .a libraries. Some
people
Albert Chin [EMAIL PROTECTED] writes:
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++ isn't specified, I don't want AC_PROG_CXX dragged in.
It'd be nice to have both an autoconf-time AC_LIBTOOL_TAGS and
Bruce Korb [EMAIL PROTECTED] writes:
Next step is CVS, but meanwhile, this is the command line
in the failing shell script:
exec $program ${1+$@}
I'm not sure I understand the full circumstances, but perhaps it's the
dodgy word splitting in zsh described in the autoconf manual Shell
Bruce Korb [EMAIL PROTECTED] writes:
2. At configure time, libtool's configury magic would grope around the
system for a shell that understands the exec $program ${1+$@}
construct.
Hopefully it's not necessary to probe for a shell, but rather just
write something simple enough to
Robert Boehne [EMAIL PROTECTED] writes:
I'm just about to make the release of Libtool 1.5. If anyone would
like to test the current CVS on their favorite platform and report
any problems, please do so! If not, your woes may have to wait for
1.5.1.
Perhaps we could have the fix for OSF with
Albert Chin [EMAIL PROTECTED] writes:
Is setting a custom -DPIC really necessary?
I wouldn't think so. It's just if it's going to be removed then a way
to ask for it back would be nice.
How about we just leave the existing -DPIC for the C and C++ tags?
Sounds good to me.
Robert Boehne [EMAIL PROTECTED] writes:
All good ideas, and I don't really have a preference for any of them.
If you do, let me know or I'll just pick the one that looks easiest.
I'd think an autoconf macro would be ok, to be used for instance
AC_LIBTOOL_PICDEF([-DPIC])
Robert Boehne [EMAIL PROTECTED] writes:
Yet again I am suprised by the diversity of uses for Libtool,
I hadn't imagined this m4-asm script. I am curious as to what tag
it uses, the plain old C (empty) tag?
Yes, the rule for automake looks like
.asm.lo:
$(LIBTOOL) --mode=compile
Robert Boehne [EMAIL PROTECTED] writes:
How about an option to configure --define-for-pic=-DPIC? Users
could defeine whatever symbol they like, rather than Libtool specifying
this.
You mean an option to the libtool script? Sounds ok. I wouldn't
think it'd need to be an actual configure
Robert Boehne [EMAIL PROTECTED] writes:
I would also like
to ask anyone who does depend on this to let us know when/where/why
how
so we can add a section to the documentation on how to modify
code to not need -DPIC.
In GMP we have assembler code (mainly i386) which understands it has
to be
Steve Ellcey [EMAIL PROTECTED] writes:
Should I just tell the user to do two builds,
with different options and different install directories?
For what it's worth, in GMP that's what we've done.
In principle there could be different libc functions and stuff in
different ABIs, so a fresh run
Tor Lillqvist [EMAIL PROTECTED] writes:
I have experienced that the 8192 (umm, don't remember exactly, some
pretty low limit anyhow) wasn't enough for GTK+, and libtool started
to use some workaround, which then failed in a mysterious
way.
In GMP we had a problem with the ar cru used for
Samuel Meder [EMAIL PROTECTED] writes:
I'm using the latest alpha libtool alpha (1.4d) and would like to be
able to turn of detection of the C++ compiler and preprocessor.
I've had some joy from setting a default value for --with-tags, as per
the following with $want_cxx determining whether
Guido Draheim [EMAIL PROTECTED] writes:
Well, in a way it is a social problem - people who do crossgcc
from unix-type platforms to win32-pe, most of them do not actually care
...
Oh well, I guess that's me :-). I ran it up to see if it worked (with
GMP), I don't actually even have a w32
I tried using the Debian packaged mingw32 cross-compiler to build a
windows DLL with cvs libtool but didn't at first realize I had to set
HOST_CC manually. Perhaps libtool could probe for a build system
compiler itself when it needs one (for impgen.c).
I don't have an actual patch to suggest
Solaris 2.7 and HP-UX 10 don't think much of
rm -f
it provokes a bit of an error
rm: cannot remove `.' or `..'
This arises from libtool when compiling, I think due to $output_obj
being empty when -c -o works.
This is no more than cosmetic, but perhaps cases where that might
I had the misfortune to try cvs libtool on hppa2.0-hp-hpux10.20 with a
version of the unbundled cc that prints the following warning when +O3
is used with +Z,
cc: warning 8006: Do not use optimization levels higher than 2 to generate a
shared library if a user of that library may
[EMAIL PROTECTED] writes:
If you replace the delimiter with a character other than /, does the
sed command work?
Yes, colons worked in last nights build.
--- libtool.m4.old Thu Oct 4 01:40:53 2001
+++ libtool.m4 Thu Oct 4 01:42:27 2001
@@ -1446,7 +1446,7 @@
for tagname in $tagnames;
I think I've struck a bit of a problem trying the cvs libtool with
GMP. GMP has some object files with the same name, like mpz/random.lo
and mpn/random.lo. On vax-dec-ultrix4.5, libtool decides the command
line limit is 3073, and does the final libgmp library link in two
pieces. Unfortunately
On an sv1-cray-unicos10.0.0.X with the cvs libtool I noticed the
following error,
configure: creating libtool
sed: 1: s/[-_ABCDEFGHIJKLMNOPQR ...: RE error: [ ] imbalance or syntax error
appending configuration tag CXX to libtool
which I think might be from
In the libtool.m4 ltdll_cmds setup for old cygwin there's a [$]0 which
comes through to the configure script verbatim, for instance in the
libtool 1.4 configure script itself. Perhaps it should be $''0 as per
the similar impgen.c extraction.
___
I was looking at the libhello DLL example, with a view to doing
something similar, and wondered whether hello.h needed to be told
whether it's being used within the libhello build before it pays
attention to DLL_EXPORT.
If hello.h was used by another package building a libfoo DLL with
libtool,
Gary V. Vaughan [EMAIL PROTECTED] writes:
The problem is that libtool.m4 jumps through a bunch if hoops to
find an echo that doesn't interpret backslashes, since it is quite a
common problem, which causes libtool a lot of headaches.
Sorry I'm a bit thick, I've not been addressing the
Chris Leishman [EMAIL PROTECTED] writes:
Everything compiles ok, but the dlopen fails with the error "not a
Mach-O MH_BUNDLE file type" (this error message is output by dlcompat
when NSCreateObjectFileImageFromFile returns
NSObjectFileImageInapproriateFile).
Perhaps the backtick quoting
On Friday 13 April 2001 2:22 am, Kevin Ryde wrote:
Without wanting to repeat myself, I posted libtool-patches in January
about SCO 5 and -lc on shared libraries, but the problem still exists
in 1.3d and the current cvs.
Something like below (re-diffed for current libtool.m4
I wrote:
so maybe it's sed.
Or maybe not.
eval "bar=\\\"\` echo \"\$quote\" \`\\\""
echo $bar
in bash gives what I assume is the expected result
"s/\([\\"\\`$]\)/\\\1/g"
whereas on Darwin
"s/\([\\"\\`$]\)/\1/g"
Actually Darwin /bin/sh looks like it's zsh (should
I think I was getting a bit off track before. Some cut down bad
behaviour can be seen, I think, from a file "foo" containing the
following
blah blah \\\` blah blah
and run a script
if test -n "$ZSH_VERSION"; then emulate sh; fi
eval "bar=\\\"\`cat foo\`\\\""
cat EOF
bar is: $bar
EOF
in ash
On Darwin 1.3 with libtool 1.3d or the current cvs, the quoting of
archive_cmds provokes a warning about an unmatched ". It comes
through to the generated libtool script as the following long line,
archive_cmds="\$CC \\`test .\$module = .yes echo -bundle || echo -dynamiclib\\`
Without wanting to repeat myself, I posted libtool-patches in January
about SCO 5 and -lc on shared libraries, but the problem still exists
in 1.3d and the current cvs.
Something like below (re-diffed for current libtool.m4) will be much
wanted, since it avoids seg faults if a shared library
On Tue, Jan 16, 2001 at 01:50:57PM +1100, Brian May wrote:
Oh, another observation: installing the libraries in their non-final
location (as required for Debian packaging tools, probably Redhat too)
simply does not work, as shown below. I think some of the required -L
options to the
34 matches
Mail list logo
