Using a recent (17 March) libtool snapshot on SunOS 4.1.4 with its
native tools, I'm finding that ranlib doesn't seem to be run when
building a static library. The relevant part of the generated libtool
script comes out as,
# Commands used to build and install an old-style archive.
RANLI
I'm using the current cvs libtool on aix 4.3 with gcc and I ran into a
couple of problems.
./libtool --mode=link gcc -g -o libfoo.la \
-rpath /usr/local/lib -version-info 4:0:1 foo.lo
ends up running
gcc -shared -o .libs/libfoo.so.3.1.0 foo.o -Wl,-bexpall \
-Wl,-bnoentry ${wl}-
> 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
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\\`
\$allow_undefi
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 uses
> 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.
>
> > Somethi
"Gary V. Vaughan" <[EMAIL PROTECTED]> writes:
>
> It looks like the echo command found by libtool is removing some of the
> backslashes that it is supposed to leave behind.
Yep.
> And this is what I get:
>
> $ echo $bar
> "\\\`"
Yep, on i386 debian or freebsd.
> I guess you will get:
>
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 ha
"Gary V. Vaughan" <[EMAIL PROTECTED]> writes:
>
> Oh dear. I thought zsh was sane enough to do the right thing when
> argv[0] == /bin/sh =(O| I take it that it is zsh builtin echo that
> is the culprit here. Does /bin/echo work correctly?
No, gives the same. And my own program doing a printf i
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 < \ gets done. Don't know if t
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 quot
"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
"Gary V. Vaughan" <[EMAIL PROTECTED]> writes:
>
> Have either of you had any success with my workaround?
>
>make ECHO="/bin/sh `pwd`/libtool --fallback-echo"
>
> Or something equivalent...
Not quite sure I understand. Should that be ECHO=/bin/echo on the
configure command? Doesn't seem t
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.
___
Libtoo
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, th
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 _LT_AC_TAG
[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 $tagnam
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 o
Maybe this is a dumb question, but is it possible, by which I mean
portable, to put comments in the symbol file used with
-export-symbols?
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
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 for
Guido Draheim <[EMAIL PROTECTED]> writes:
>
> http://ac-archive.sf.net/Installed_Packages/patch_libtool_to_add_host_cc.html
Thanks, I missed that one, I ended up patching libtool.m4.
> But this is not
> actually the Right Thing, dlltool should offer an option about it,
> and since dlltool is pre
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
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 redefin
Robert Boehne <[EMAIL PROTECTED]> writes:
>
> Could you try changing AR_FLAGS in your libtool script
> to see if that works?
AR_FLAGS=cq seems to work on all the systems I've tried, and fixes the
ultrix problem. As long as ranlib does its job then I imagine it'd
have to work everywhere.
___
Robert Boehne <[EMAIL PROTECTED]> writes:
>
> What's the Ultrix problem?
It was vax-dec-ultrix4.5 which had the small command line limit and
suffered in the piecewise link.
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinf
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
Olly Betts <[EMAIL PROTECTED]> writes:
>
> ## We must test each macro because it might be empty, and an empty "rm
> ## -rf" command looks disturbing. Also, the Solaris 2.4 "rm" will
> ## return an error if there are no arguments other than "-f".
Soor, I pruned too much, the libtool case is inst
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 wheth
Samuel Meder <[EMAIL PROTECTED]> writes:
>
> Passing a empty with_tags does only turn of the GCJ stuff. C++
> detection is still done.
Oops, I forgot the key is to have AC_PROG_CXX and AC_PROG_CXXCPP
expanded, but only executed when desired. The dead hand of AC_REQUIRE
I suspect :-).
Actual exa
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" use
Bob Friesenhahn <[EMAIL PROTECTED]> writes:
>
> Comments?
Is it still true that global variables exported from a dll must have a
dllimport directive for applications? AC_LIBTOOL_WIN32_DLL would
perhaps indicate a package has addressed this issue (by whatever
means) and is therefore dll safe.
__
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 r
For cxx on "osf4* | osf5*", libtool uses
printf "-exported_symbol "
as part of archive_expsym_cmds. Unfortunately bash 2.05b objects to
this with
printf: -e: invalid option
The bash doco doesn't mention any options for printf, but I suppose it
parses them in the usual way. Unl
I wrote:
>
> Using "printf -- -exported_symbol " seems to work with both bash and
> /usr/bin/printf. Unless anyone knows better perhaps this would be a
> good change.
Ah, sorry, I just tried "dash", the Almquist shell on Debian, and its
builtin gives "--" for "printf --". A better way to avoid a
Bruce Korb <[EMAIL PROTECTED]> writes:
>
> Any particular problem with:
>
> echo '-exported_symbol '
Offhand I can't give an example problem, but autoconf "Limitations of
Builtins" specifically advises against trying to echo anything
starting with "-".
_
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 h
"Boehne, Robert" <[EMAIL PROTECTED]> writes:
>
> Wouldn't replacing -DPIC with -D__PIC__ break a fundamental
> assumption about ANSI compilers, that "__" means compiler-defined
> and not in the userspace?
I had an idea FOO was for applications, _FOO for the compiler, and
__FOO for third party libr
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=compil
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 conf
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])
AC
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:
>
> 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 OS
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 "She
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
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 a
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
peop
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.
Guido Draheim <[EMAIL PROTECTED]> writes:
>
> +jvm | java | jvm-java)
> + basic_machine=jvm-sun
As a suggestion, put "unknown" not "sun" there, if you don't know the
vendor.
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu
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]
http:
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 versio
51 matches
Mail list logo
