> "Thomas" == Thomas Tanner <[EMAIL PROTECTED]> writes:
Thomas> I wonder why automake passes CFLAGS and AM_CFLAGS
Thomas> to libtool in link mode? This makes it impossible
Thomas> to differentiate between compiler and linker (LDFLAGS)
Thomas> flags.
The GNU Coding Standards mandate this.
> "Michael" == Michael Bletzinger <[EMAIL PROTECTED]> writes:
Michael> The first issue is: Where should the common configuration
Michael> information needed to build the various subpackages be
Michael> stored?
It depends on your goals.
Michael> I would like to set up a base package for the
> "Gary" == Gary V Vaughan <[EMAIL PROTECTED]> writes:
Gary> For some reason, libtool and automake are conspiring to pass
Gary> gcc's dependency generation options (-Wp,-MD,.deps/dtedio.pp) to
Gary> your MIPSpro compiler. I *think* you might need to use an
Gary> automake from after the `depg
Alexandre> Anyway, on platforms that actually require relinking, this
Alexandre> problem remains, and I see no way to overcome it other than
Alexandre> arranging for automake to install libraries before
Alexandre> executables, as you suggest. This shouldn't be a big
Alexandre> problem, anyway.
N
>> Do I have to use some macro in configure.in to fill $(LINK) with GNU ld?
Alexandre> automake should define it to `$(LIBTOOL) $(CC/CXX)...'.
Alexandre> Maybe it only does this when there is at least one source
Alexandre> file to compile in the current directory?
Yeah, that's how it works. I r
> "Patrick" == Patrick Guio <[EMAIL PROTECTED]> writes:
Patrick> I am not sure if this is to be adressed to libtool or maybe
Patrick> automake since the problem might come from depcom... Anyway
Patrick> I am trying to build a c++ library using libtool on a
Patrick> alphaev6-dec-osf5.0 using
> "Ben" == Ben Elliston <[EMAIL PROTECTED]> writes:
Ben> When running libtool (in, say, compile mode), libtool echoes the
Ben> command line used to invoke the compiler. This is very
Ben> informative, but on systems where I like to use `make -s' to
Ben> minimise `make' output across slow remo
> "Alexandre" == Alexandre Oliva <[EMAIL PROTECTED]> writes:
Alexandre> I think I wouldn't reject a patch that would look at
Alexandre> MAKEFLAGS and turn libtool quiet if it finds a -s in
Alexandre> there...
Automake could do this too. But it will just make the Makefiles even
more complica
> "David" == David Lee <[EMAIL PROTECTED]> writes:
David> But any such project would, I think, have a "libtool"
David> interaction, and I know almost nothing about the insides of
David> libtool. It would seem to require a variant of "libtool
David> --mode=install" that doesn't actually do th
> "Jeremy" == Jeremy Slade <[EMAIL PROTECTED]> writes:
Jeremy> What I really want to build is 'swigShapeUtils.sl', which
Jeremy> corresponds to the swigShapeUtils.pm module. But automake
Jeremy> complains:
Jeremy> automake: src/perl/swig/Makefile.am: `swigShapeUtils.la' is not a
Jeremy> sta
> "Alexandre" == Alexandre Oliva <[EMAIL PROTECTED]> writes:
>> If Automake doesn't support $ in source file names, then I would
>> suggest that it isn't an important requirement for Libtool.
Alexandre> I disagree. libtool can be used independently from
Alexandre> automake. And, in fact, u
> "Patrick" == Patrick Guio <[EMAIL PROTECTED]> writes:
Sorry for the long delay in my reply to this...
Patrick> I am not sure if this is to be adressed to libtool or maybe
Patrick> automake since the problem might come from depcom...
Could be either.
Patrick> Anyway I am trying to build a
--enable-shared has the nice feature of letting the user choose what
packages should have shared libraries. For instance in the gcc tree I
could configure with --enable-shared=libgcc,libgcj to enable just
those shared libraries.
However, it turns out that in this same situation, libgcj really ne
> "Gary" == Gary V Vaughan <[EMAIL PROTECTED]> writes:
Gary> I'm leaving the text of your email intact for the benefit of new
Gary> readers on [EMAIL PROTECTED] It appears that the problems you
Gary> are experiencing are caused by the automated compiler dependency
Gary> generation code in au
> "Ted" == Ted Irons <[EMAIL PROTECTED]> writes:
Ted> I keep seeing the macro
Ted> MAINTAINERCLEANFILES in the
Ted> excellent Autoconf Book (G. Vaughan, et.all )
Ted> but can't find where MAINTAINERCLEANFILES
Ted> is defined. I've looked in the produced
Ted> aclocal.m4 and in the info page
t calling "install-info" in that case,
Peter> but "uninstall" does not.
The rules in texinfos.am look like they both do the same thing
regarding install-info.
Peter> Tom Tromey said to me something along the lines that uninstall
Peter> is of too little use to bother
> "Gary" == Gary V Vaughan <[EMAIL PROTECTED]> writes:
Gary> A short while before the libtool-1.4 release, Edward M. Lee
Gary> posted a joint patch to libtool and automake which takes care of
Gary> the worst of this sort of thing. I applied the libtool parts
Gary> before the release but the
> "Martin" == Martin Hollmichel <[EMAIL PROTECTED]> writes:
Before I address your points, or at least the ones I plan to address,
I thought first I would write my own critique of the auto tools.
While I do think that these tools have deep problems, I also think you
largely avoided mentioning
> "Robert" == Robert Collins <[EMAIL PROTECTED]> writes:
Robert> Is this a bug, or a non-existant feature?
Robert> symptoms:
Robert> automake's makefile calls libtool:
Robert> STRIPPROG='strip' /bin/sh ./libtool --mode=install -s hello.exe
Robert> /usr/src/hellolib/build/t
Robert> /usr/loc
> "Pierre" == Pierre Sarrazin <[EMAIL PROTECTED]> writes:
Pierre> Logically, it is in a Makefile.am file that I would like to
Pierre> ask that a specific library should be static.
If you are trying to build a static library, then simply don't use
libtool for that library. Write `lib_LIBRARI
> "adl" == Alexandre Duret-Lutz <[EMAIL PROTECTED]> writes:
adl> I can reproduce your problem by manually setting compiler_c_o and
adl> compiler_o_lo to "no" in the libtool script generated for a
adl> pet-project. So ...
adl> As an immediate work-around, you can prevent `depcomp' to add
adl
> "Alexandre" == Alexandre Oliva <[EMAIL PROTECTED]> writes:
Alexandre> In general, I recommend specifying the tag name explicitly,
Alexandre> like some Makefiles already do, and automake should
Alexandre> eventually do.
Could you submit an automake PR for that?
Otherwise I guarantee we'll f
> "Albert" == Albert Chin <[EMAIL PROTECTED]> writes:
>> program_LIBADD=$(libdir)/libsomething.la
>> Is there a way of telling automake that libsomething.la may be in any of
>> several directories?
Albert> What version of automake are you using? This isn't a libtool
Albert> question
> "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.
Tom
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman
> "Albert" == Albert Chin <[EMAIL PROTECTED]> writes:
>> The support is in automake.
Albert> That doesn't help when running autoconf though. Specifically,
Albert> from libtool.m4:
I meant that the variable is set in an autoconf macro that is supplied
with automake.
Albert> Shouldn't autoco
> ">" == F J Franklin <[EMAIL PROTECTED]> writes:
I didn't see a reply to this. Sorry for the long delay...
>> I'd like to add in support for Objective-C (*.m) and Objective-C++ (*.mm).
>> I know about the work-around using the suffix rule, but it doesn't handle
>> dependencies...
Automake
> "Bob" == Bob Friesenhahn <[EMAIL PROTECTED]> writes:
Bob> This may be because the mail archive is in HTML format, and
Bob> saving to text makes it subject to the formatting whims of my
Bob> browser. I also saved directly to HTML but that actually did
Bob> worse.
FWIW: I find the appended s
> "Asim" == Asim Suter <[EMAIL PROTECTED]> writes:
Asim> 1) Which tool/script/program generates .Po/.Plo files ? And at what
Asim> stage ?
They are initially created, as empty files, by configure when building
the various Makefiles.
Then, they are updated as a side effect of compilation.
As
> "Alexandre" == Alexandre Oliva <[EMAIL PROTECTED]> writes:
Alexandre> the *_OBJECT definitions assume the absence of shell-active
Alexandre> characters in filenames, which is probably a safe
Alexandre> assumption for Makefiles.
It isn't unreasonable for a Java .class file's name to contain
29 matches
Mail list logo
