Re: GNU Coding Standards, automake, and the recent xz-utils backdoor
On Mar 30, 2024, Eric Gallager wrote: > automake's `distcheck` target, whose entire purpose is to make it > easier to verify that a distribution tarball can be rebuilt from > itself and contains all the things it ought to contain. > Recommending the `distcheck` target to a wider variety of users would > help more projects catch mismatches between things a distribution > tarball is supposed to contain, and things that it isn't. This would > be a win for security and could help make it easier to catch future > possible bad actors trying to pull a similar trick. What do people > think? Bluntly, I don't think it would help with security. The attacker would just have to disable or adjust the distcheck target to seemingly pass. Relying on something in a code repository to tell whether the repository is secure is akin to tying a dog with sausage. For security proper, the verification code needs to be held elsewhere, not compromisable along with the thing it's supposed to verify. Analogously, you don't run a rootkit checker on the system that's potentially compromised, because the rootkit may hide itself; you boot off secure media and then use the tools in it to look for the rootkit in the potentially-compromised system, *without* handing control over to it. -- Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/ Free Software Activist GNU Toolchain Engineer Disinformation flourishes because many people care deeply about injustice but very few check the facts. Think Assange & Stallman. The empires strike back
Re: Need a way to pass options to libtool
On May 26, 2004, Albert Chin [EMAIL PROTECTED] wrote: On Sun, May 23, 2004 at 03:20:35PM -0500, Bob Friesenhahn wrote: Notice that there is no means provided to add libtool specific options. Why not: AM_CXXFLAGS += [your additions] Because that's also passed to non-libtool compilations? I've often wanted some means to pass additional flags to libtool compile and/or link commands without affecting non-libtool compile and/or link. My favorite example is -static, that has a somewhat different meaning when it comes to libtool. -- Alexandre Oliva http://www.ic.unicamp.br/~oliva/ Red Hat Compiler Engineer [EMAIL PROTECTED], gcc.gnu.org} Free Software Evangelist [EMAIL PROTECTED], gnu.org}
Re: automake depcomp under more open license
On Jul 17, 2001, Tom Tromey [EMAIL PROTECTED] wrote: Sven == Sven Verdoolaege [EMAIL PROTECTED] writes: Sven Would it be possible to include a version of depcomp with a Sven GPL exemption similar to what was added to 'missing' recently Sven in automake ? I think that is reasonable. I added it. Alexandre, complain if you have a problem with it. A bit late, but... I don't have a problem with it :-) -- Alexandre Oliva http://www.ic.unicamp.br/~oliva/ Red Hat Compiler Engineer [EMAIL PROTECTED], gcc.gnu.org} Free Software Evangelist [EMAIL PROTECTED], gnu.org}
Re: [MAD SCIENCE EXPERIMENT]: Replace some libtool functionality with handcoded C
On Dec 9, 2003, Tom Tromey [EMAIL PROTECTED] wrote: 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 $. Oh, but if you look closely at the macros I posted, you'll notice that this doesn't matter all that much. As long as the automake- or hand-generated definition of ofile doesn't contain shell-active characters (and IIRC automake already takes care of turning them into underscores), you're fine. And then, if it does, we need an additional variable set by the rule preamble that sets a shell-safe version of ofile. The point here is to avoid the overhead of having to run ofile through sed to protect it at build time, when we can do it at Makefile-generation time. -- Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/ Red Hat GCC Developer [EMAIL PROTECTED], gcc.gnu.org} CS PhD student at IC-Unicamp[EMAIL PROTECTED], gnu.org} Free Software EvangelistProfessional serial bug killer
Re: [MAD SCIENCE EXPERIMENT]: Replace some libtool functionality with handcoded C
On Dec 3, 2003, Mohan Embar [EMAIL PROTECTED] wrote:
I wanted to see how much faster the libgcj build would go if I took
libtool out of the picture for some of the pieces.
I'm not all that surprised your C program is much faster that the
shell script. For starters, it fails to support all of libtool's
configure-time options, such as --disable-static, --disable-shared,
--with-pic, as well as their per-compilation equivalent command-line
flags.
That said, even if it supported them all, I do believe there's a lot
of potential for such code. It has been in libtool's roadmap since
long before I pretty much stopped working on libtool, which was a
while before release 1.5. There were a number of discussions about
doing in C what we currently do in a slow and unmaintainable shell
script. Gary V. Vaughan had a small language with a small interpreter
that could reasonably be bundled into a libtool package as a
replacement for ltconfig/ltmain.sh, but we never got as far as
integrating it an actually making the transition. I suppose if you'd
like to do that, it would be very welcome, since many people
(rightfully) complain about libtool slowing things down, and using a
fast shell with many built ins isn't quite enough to get builds fast.
Back during the GCC summit, Zack Weinberg suggested an alternative
approach that could speed things up: getting the libtool code to
define additional Makefile macros that would enable someone to inline
the libtool calls into the Makefile itself. We talked a lot about it,
and it seems to me that if we got libtool to define the macros
referenced below and automake to generate them, we could have some
significant speed up by avoiding the need for the shell to at least
parse the entire libtool script for every command. That said, we
might be able to achieve similarly good results by simply splitting
the several libtool --modes into separate files, that could then be
ran with `.', which would at least minimize parsing.
foo.lo: foo.c
lofile=$@ dir=. ofile=foo.o; \
$(LIBTOOL_BEGIN_COMPILE_CC) FLAGS foo.c \
$(LIBTOOL_END_COMPILE_CC)
given the following possible additional definitions: (yeah, it's ugly,
and I sort of doubt we can get AC_SUBST to portably emit
LIBTOOL_END_COMPILE_CC like the snippet below, but hey!, it *might*
work, even if we have to break it up in smaller pieces to avoid
running into hard-coded limitations of sed substitutions)
LIBTOOL_BEGIN_COMPILE_CC = set fnord \
LIBTOOL_END_COMPILE_CC = ; shift 1; \
{ test -d $$dir/$(libtool_libdir) || \
$(mkdir_p) $$dir/$(libtool_libdir); } \
rm -f $$lofileT $$lofile $$dir/$$ofile \
$$dir/$(libtool_libdir)/$$ofile || : ; \
$(LIBTOOL_COMPILE_CC_PIC) -o $$dir/$(libtool_libdir)/$$ofile \
$${1+$$@} \
$(LIBTOOL_COMPILE_CC_NONPIC) -o $$dir/$$ofile $${1+$$@} \
{ echo pic_object=$(LIBTOOL_PIC_OBJECT); \
echo non_pic_object=$(LIBTOOL_NONPIC_OBJECT); } $$lofileT \
mv $$lofileT $$lofile
mkdir_p = mkdir -p # or $(mkinstalldirs), depending on configure tests
libtool_libdir = .libs # or _libs, depending on configure tests
LIBTOOL_COMPILE_CC_PIC = $(CC) -fPIC -DPIC # or equivalent, or :
LIBTOOL_COMPILE_CC_NONPIC = $(CC) # or : if disable static
LIBTOOL_PIC_OBJECT = $(libtool_libdir)/$$ofile # or none
LIBTOOL_NONPIC_OBJECT = $$ofile # or none
the *_OBJECT definitions assume the absence of shell-active characters
in filenames, which is probably a safe assumption for Makefiles. In
case libtool configuration finds that $(CC) is not up to e.g. the task
of outputting to object files named in the command line, it just falls
back to running the slow libtool script, with these definitions:
LIBTOOL_BEGIN_CC_COMPILE = $(LIBTOOL) --mode=compile $(CC) -o $$lofile
LIBTOOL_END_CC_COMPILE =
The best news is that we don't really need to modify libtool to play
with these ideas. We can play with the idea with a new set of
autoconf macros that extracts configuration variables from libtool
with --config and defines the appropriate AC_SUBST variables according
to them, then use custom build rules instead of automake-generated
ones. If it proves to be a good idea, the macros can be bundled with
libtool, and then automake can gain an option to generate such rules.
It will need a lot of experimenting, and some polishing of the macro
set that I posted above, but I believe you can realize most of the
gains you intend to realize with it, and then you won't be introducing
the need for running yet another program.
Wanna give it a try?
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer [EMAIL PROTECTED], gcc.gnu.org}
CS PhD student at IC-Unicamp[EMAIL PROTECTED], gnu.org}
Free Software EvangelistProfessional serial bug killer
Re: PATCH: Use libgcj_convenience.la ( Re: libjava bootstrap failure on sparc-sun-solaris2.8)
[CC:ing automake mailing list]
On Jun 7, 2002, Hans-Peter Nilsson [EMAIL PROTECTED] wrote:
On 5 Jun 2002, Alexandre Oliva wrote:
What -static doesn't mean to libtool is to reject any kind of dynamic
linking. -all-static does that [...]
But -all-static isn't a valid gcc option. When in a tree such
as the binutils+gcc+whatnot, it's nice to be able to pass
CC=gcc -static in the toplevel at configure time, and know
that everything is statically linked. (And no, that doesn't
work with unpatched libtool.) Passing CC=gcc -all-static
would work if every subdirectory used libtool everywhere, but
just plain where they don't.
I agree the non-standard meaning of -static in libtool is unfortunate,
but IIRC I inherited it that way, and never had the courage to change
it :-)
A way I thought to alleviate this problem would be to get automake to
support say LT_LDFLAGS, such that to make sure you get only
statically-linked binaries, you could use `CC=gcc -static' and
`LT_LDFLAGS=-all-static'. Automakers, what do you think? Should I
file a PR with this suggestion?
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software EvangelistProfessional serial bug killer
Re: Feature suggestion
On Jun 20, 2001, Tom Tromey [EMAIL PROTECTED] wrote:
Lately I've been thinking that it was a mistake to introduce
_LTLIBRARIES as a parallel primary to _LIBRARIES. I think we could
just have _LIBRARIES and then base decisions on the extension. This
would also let us use the same mechanism for Java jar and zip files.
Wow! Excellent idea!
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist*Please* write to mailing lists, not to me
Re: missing does not support configure.ac in CVS or in 1.4-p4
On Jun 11, 2001, Akim Demaille [EMAIL PROTECTED] wrote:
Gary == Gary V Vaughan [EMAIL PROTECTED] writes:
Gary Thanks. Applied on branch-1-4. If there is an automake-1.4-p5,
Gary this will be in it!
Applied on HEAD.
Is it really correct to assume that $PWD = $top_srcdir when running
missing? The test in the patch assumes so, but I'm not sure this
assumption holds for all uses of `missing'.
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist*Please* write to mailing lists, not to me
Re: AM_CFLAGS and sub/foo.c
On Jun 15, 2001, Steve M. Robbins [EMAIL PROTECTED] wrote:
I normally want the program-specific flags _in addition_ to the
generic flags. So I *always* have $(LDADD) in $foo_LDADD.
But consider the case of not wanting $(LDADD) in foo_LDADD. Or
consider cases in which the order matters, and you need control over
where $(LDADD) appears in foo_LDADD. I think the only way to do this
right is to defer the decision to the user, which means not having it
included by default. Which is a good thing in itself, because it lets
one omit LDADD completely.
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist*Please* write to mailing lists, not to me
Re: Patches in Gnats?
On Jun 14, 2001, Tom Tromey [EMAIL PROTECTED] wrote:
I was thinking I could create a new `patch' category in the automake
Gnats and ask people to put such patches there as attachments. What
do people think of this?
You can't reliably extract patches from Gnats.
Savannah.gnu.org has a nice patch tracking system (for those who like
this kind of thing; not me :-); perhaps we could use it?
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist*Please* write to mailing lists, not to me
Re: missing does not support configure.ac in CVS or in 1.4-p4
On Jun 17, 2001, Martin Dickopp [EMAIL PROTECTED] wrote:
I made this assumption without checking it, because the current
(1.4-p4) missing makes the same assumption. It contains the line
files=`sed -n 's/^[ ]*A[CM]_CONFIG_HEADER(\([^)]*\)).*/\1/p' configure.in`
in the autoheader case.
Autoheader is indeed always run with PWD = top_builddir.
Looking closer at the script, I notice that it also seems to assume
$PWD = $top_srcdir = $top_builddir.
I doubt it. I've certainly used it with srcdir != builddir.
It's likely that assumptions change depending on which program is
`missing'.
Anyway, I've just realized that your change affects only aclocal,
autoconf, autoheader and automake emulations, and all of these are
always run off top_srcdir, so the change is safe, even though it sets
a precedent that might lead others to conclude missing is always run
off top_srcdir (since the test for configure.ac is always done). I'd
appreciate a comment before the test explaining why it is safe to do
the test there even though missing isn't always guaranteed to run in
the directory containing configure.{in,ac}.
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist*Please* write to mailing lists, not to me
Re: Recursive make harmful
On Jun 1, 2001, Alexandre Duret-Lutz [EMAIL PROTECTED] wrote:
Richard With separate Makefile.am's in each directory,
Richard automake should be able to figure the bar/foo out from
Richard the directory paths. The user shouldn't have to worry
Richard about what the path to the top-level is.
Is this really possible? Makefile.am files may contains rules
which need to be patched if you move them at another level.
If you're talking about the commands, I believe it's relatively easy
to cope with this problem: just generate, in the top-level Makefile, a
rule that runs the corresponding rule in the sub-make.
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist*Please* write to mailing lists, not to me
Re: texinfo problem
On May 29, 2001, Tom Tromey [EMAIL PROTECTED] wrote:
Alexandre == Alexandre Oliva [EMAIL PROTECTED] writes:
I've noticed that if you try to build a texi file that has an error
you get a warning from the `missing' program:
Alexandre Presumably missing should check, when the execution of a
Alexandre program fails, whether the program can be found in the PATH
Alexandre or not, and only report its warning if it finds the program
Alexandre is indeed missing.
Right now AM_MISSING_PROG looks like this:
I was not thinking of AM_MISSING_PROG, but of the missing script
itself.
Currently, we have:
case $1 in
--run)
# Try to run requested program, and just exit if it succeeds.
run=
shift
$@ exit 0
My suggestion is to add a PATH search for $1 right after this command,
and just bail out if we find it, without getting a chance to print the
warning.
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist*Please* write to mailing lists, not to me
Re: automake 1.4g: About `make install-strip'
On May 26, 2001, Tom Tromey [EMAIL PROTECTED] wrote:
Alexandre == Alexandre Oliva [EMAIL PROTECTED] writes:
Note that I'm writing of a performance. Install-sh is a serious
performance hit for non-trivial installs.
Alexandre How about only use install-sh for install-strip on cross builds?
I'm ok with this idea. Can it be easily done with autoconf 2.13
compatibility?
Not easily. cross_compiling used to be set only after compiler tests
in 2.13. But we could just compare $host with $build, like 2.50 does,
to decide whether to use install-sh -s or install -s. How does this
sound?
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist*Please* write to mailing lists, not to me
Re: automake 1.4g: About `make install-strip'
On May 24, 2001, Maciej W. Rozycki [EMAIL PROTECTED] wrote:
On 23 May 2001, Tom Tromey wrote:
This is possible, but we don't recommend it. Instead we try to
approach cross builds the autoconf way: we assume that configure
will use things like AC_CHECK_TOOL, etc.
Note that I'm writing of a performance. Install-sh is a serious
performance hit for non-trivial installs.
How about only use install-sh for install-strip on cross builds?
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist*Please* write to mailing lists, not to me
Re: Two new mailing lists
On May 19, 2001, Akim Demaille [EMAIL PROTECTED] wrote:
Automake now has two new Mailman mailing lists:
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-automake
So, did you move the subscribers of the original bug-automake mailing
list over to Mailman, or am I going to have to subscribe again?
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist*Please* write to mailing lists, not to me
Re: *_TEXINFOS
On May 17, 2001, Tom Tromey [EMAIL PROTECTED] wrote:
Sometimes I wonder if this is really the right thing to do.
Perhaps it should be an option?
I often use read-only srcdir myself, so I'd like to have this
possibility. Anyway, since we do update files that are part of the
distribution (think configure and Makefile.in), modifying info files
doesn't really add much.
OTOH, since `make dist' will now pick files from the builddir instead
of srcdir, if they exist in the builddir (unless my memory is failing
badly :-), creating files in the build tree wouldn't make much of a
difference for maintainers anyway. Unless they wrote Makefile rules
that depended on the fact that files were in the build tree, in which
case they'd be in trouble. `make distcheck' would hopefully tell them
so.
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist*Please* write to mailing lists, not to me
Re: depcomp used but not installed
On May 17, 2001, Pavel Roskin [EMAIL PROTECTED] wrote:
AM_DEPENDENCIES should be more quiet if it cannot find depcomp.
I think this would be a good compromise. Assuming depmode=none would
be fine, in this case.
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist*Please* write to mailing lists, not to me
Re: 2 questions on automake
On May 16, 2001, Reinhard Müller [EMAIL PROTECTED] wrote:
Tom Tromey wrote:
According to my test, at least cvs automake does remove Makefile.in on
`maintainer-clean'.
It does not remove aclocal.m4 or configure, though. It should. My
test will ensure that we (eventually) fix this.
Let me add config.guess, config.sub, ltconfig, ltmain.sh [...] to
the list of proposed standard-maintainercleanfiles.
I strongly disagree. Even though these files are often imported from
central repositories, they're actually part of a package, since
they're sometimes modified to suit local needs. Removing them
shouldn't be taken lightly.
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist*Please* write to mailing lists, not to me
Re: PATCH: aclocal use ACPATH for include path ...???
On May 15, 2001, Tom Tromey [EMAIL PROTECTED] wrote:
Timshel == Timshel Knoll [EMAIL PROTECTED] writes:
Timshel I don't think I've sent this patch before (I made it ages
Timshel ago), so do you want to include this in upstream automake? It
Timshel would be a useful addition, IMHO ... the patch is against the
Timshel latest CVS automake.
I don't think I want to check this in. I dislike having environment
variables affect build tools.
If you really want an environment variable, why not just set ACLOCAL:
export ACLOCAL='aclocal -I/path/to/my/stuff'
?
Then configure ought to pick that up automatically for you.
Or have ~/bin/aclocal run /path/to/aclocal -I/path/to/my/stuff ${1+$@}
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist*Please* write to mailing lists, not to me
Re: AC_CHECK_HEADER(S) search path
On May 3, 2001, Lars J. Aas [EMAIL PROTECTED] wrote:
On Thu, May 03, 2001 at 02:33:49PM -0300, Alexandre Oliva wrote:
: On May 3, 2001, Genty Jean-Paul [EMAIL PROTECTED] wrote:
:I prefer not to put it in an environnement variable.
:
: You're out of luck, then.
I don't really consider it putting it in an environment variable if you
append it to the configure command-line.
Good point. I forgot we had this possibility now.
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist*Please* write to mailing lists, not to me
Re: Fileutils 4.1: make install-strip broken
On May 1, 2001, Andreas Schwab [EMAIL PROTECTED] wrote:
This is probably a bug in automake 1.4e.
Yep. A patch to fix is has just gone in, IIRC.
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist*Please* write to mailing lists, not to me
___
Bug-fileutils mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-fileutils
Re: crosscompiled .exe (Re: crosscompiling dll linux-mingw32)
On Apr 28, 2001, Gary V. Vaughan [EMAIL PROTECTED] wrote:
libtool would need to build a wrapper program on Windows which would
call the wrapper script to set the environment up to load the
correct DLLs and then call the actual program in the .libs
subdirectory.
I like this idea. It's been in my to-do list for a while.
Along the same lines, we should probably not even bother to create the
wrapper script/program when cross compiling. I'm not sure we already
do this.
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist*Please* write to mailing lists, not to me
Re: crosscompiling dll linux-mingw32
On Apr 26, 2001, Guido Draheim [EMAIL PROTECTED] wrote:
I did just need to change a single line in ltmain.sh which
enabled me afterwards to actually *build* a dll.
Looks like you were not using -no-undefined when creating the
library. This is required to build a DLL on MS-Windows.
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist*Please* write to mailing lists, not to me
Re: PATCH: Fix dependency tracking
On Apr 23, 2001, Robert Boehne [EMAIL PROTECTED] wrote:
Here is a patch that fixes the problems I've been winging about.
Part of the problem appears to be that @AMDEP_TRUE@ is
AC_SUBST'd when automake is generated from automake.in,
so I add a dummy variable and set it to '@AMDEP_TRUE@'
and subst that into automake.in.
Err... Would you mind posting a patch that affects only the files
you've actually modified? It's hard to find your changes inside this
huge patch with lots of unrelated changes. A ChangeLog entry would
have helped as well :-)
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist*Please* write to mailing lists, not to me
Re: Bug when specifying --disable-dependency-tracking (AM_DEP_TRACK)
On Apr 18, 2001, Robert Boehne [EMAIL PROTECTED] wrote:
.c.o:
source='$' object='$@' libtool=no @AMDEPBACKSLASH@
depfile='$(DEPDIR)/$*.Po' tmpdepfile='$(DEPDIR)/$*.TPo'
@AMDEPBACKSLASH@
$(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
$(COMPILE) -c -o $@ `test -f $ || echo '$(srcdir)/'`$
AFAICT, this was not generated by the automake that corresponds to the
new m4/depend.m4. The new version should have `#'s in the beginning
of the lines containing AMDEPBACKSLASH. This should have been a
result of the new if/endif AMDEP rules in depend2.am.
However, I see the change that introduced AMDEP as a conditional has
removed the test for the existence of the depcomp script. Hmm...
Perhaps this is not necessary, since this very script is used to
choose a dependency tracking mechanism, so we'd end up with `no' if it
doesn't exist. Yeah, that makes sense...
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist*Please* write to mailing lists, not to me
Re: problem: unitialized +=
On Apr 18, 2001, Akim Demaille [EMAIL PROTECTED] wrote:
Unfortunately it is quite unrealistic wrt the implementation: Automake
values are read _after_ Makefile.am was. Supporting this would be
hard, and I am not sure it would bring really bonus.
How about this: when you find FOO += bar but FOO is not initialized,
replace it with FOO = @FOO@ bar. It would probably cover the most
interesting cases, no? Hmm... Not the case of DEFS :-(
How about adding a mark, such as @+FOO@, that you'd replace with
the contents automake would set by default, when it gets to the point
of setting the defaults?
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist*Please* write to mailing lists, not to me
Re: problem: unitialized +=
On Apr 17, 2001, Akim Demaille [EMAIL PROTECTED] wrote:
* automake.in (macro_define): User variables can be first defined
with `+='.
My impression is that, in this case, the macro should add to whatever
automake would have set by default, instead of completely overriding
the setting.
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist*Please* write to mailing lists, not to me
Re: target dependency bug
On Apr 17, 2001, "Robert Collins" [EMAIL PROTECTED] wrote:
Thats the bug I reported: a built_source that doesn't get encoded as a
dependency by automake.
It's definitely not encoded as an explicit dependency of files that
depend on it (how would automake figure it out?), but BUILT_SOURCES
are supposed to be built before anything else. I believe this used to
require GNU make in automake 1.4, and it was broken until a few days
ago in CVS automake, but I seem to recall it is now fixed.
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist*Please* write to mailing lists, not to me
Re: target dependency bug
On Apr 17, 2001, "Robert Collins" [EMAIL PROTECTED] wrote:
If I understand you correctly, that should result in a Makefile.in with
cf_gen_defines.h as a dependancy of cf_gen.$(OBJEXT): ?
Nope. It's some other target that would depend on cf_gen_defines.h.
BUILT_SOURCES are global, not specific to some object file.
I'm testing this on my cygwin box with GNU make, automake CVS (as of
early week).
Try current CVS. I think the fix for this bug was very, very recent.
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist*Please* write to mailing lists, not to me
Re: target dependency bug
On Apr 17, 2001, "Robert Collins" [EMAIL PROTECTED] wrote:
cf_gen_defines.h is being built. But cf_gen.o isn't being updated when
cf_gen_defines.h is updated.
Did you --enable-dependency-tracking?
And AFAICT, automake has enough info to make cf_gen_defines.h a
dependency of cf_gen.o
How would it be able to it figure out? You just told it
cf_gen_defines.h is a source of cf_gen (the executable). Why should
it infer that it's cf_gen.o that depends on this header?
I think I'm confused. Are you saying that CVS may make cf_gen.$(OBJEXT)
depend on cf_gen_defines.h?
Nope. I'm saying it would make sure BUILT_SOURCES are built before
any other source files are compiled.
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist*Please* write to mailing lists, not to me
Re: target dependency bug
On Apr 17, 2001, "Robert Collins" [EMAIL PROTECTED] wrote:
I think so. I'm using gcc 2.95.3 - that does dependencies as a side
effect doesn't it ?
Yep. Check .deps/cf_gen.Po
Nope. I'm saying it would make sure BUILT_SOURCES are built before
any other source files are compiled.
Which it does.
Good. That's the sole purpose of BUILT_SOURCES.
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist*Please* write to mailing lists, not to me
Re: CVS autoconf + CVS automake = autoconf doesn't know its version
On Apr 6, 2001, "Lars J. Aas" [EMAIL PROTECTED] wrote:
On Thu, Apr 05, 2001 at 05:36:48PM -0500, Raja R Harinath wrote:
: Hi,
:
: The following patch fixes a problem with CVS autoconf, if a recent
: enough CVS snapshot of automake was used on it.
This is my proposal.
Good idea. Please check it in, this is sufficiently obviously-correct
to not require a second approval.
Thanks!
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist*Please* write to mailing lists, not to me
Re: SGI mode depcomp breaks when '.' appears in source filenames twice
On Apr 5, 2001, Raja R Harinath [EMAIL PROTECTED] wrote:
Robert Boehne [EMAIL PROTECTED] writes:
sed 's/^[^\.]*\.o://' | tr '
Try changing that to
sed 's/^.*\.o://' | tr '
This should be safe. I don't see why the original tried to avoid
'.'s. The regexp is limited to the first ':' -- so the '.*' cannot
swallow any more of the line.
Perhaps `[^:]*', just to be on the safe side?
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist*Please* write to mailing lists, not to me
Re: include Makefile.extra
On Apr 6, 2001, Reed Lai [EMAIL PROTECTED] wrote:
I cannot include an extra makefile in Makefile.am, because the
automake will error since that extra makefile is created by
configure and not exist when automake is running.
Then you should probably arrange for autoconf to expand the file into
the generated Makefile. See AC_SUBST_FILE.
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist*Please* write to mailing lists, not to me
Re: Linking Problems
On Mar 31, 2001, [EMAIL PROTECTED] wrote:
undefined reference to Namespace::Class::Method
Assuming Namespace::Class::Method is indeed defined somewhere, make
sure the library in which it is defined appears after libraries in
which it is referenced. Ordering of libraries is relevant. If there
are cross-dependencies, you may have to list libraries more than once.
You'll probably be better off creating libtool convenience libraries
in the sub-directories, and creating a single library in the top
level. An alternative is to use a CVS version of automake, that
allows sources in sub-directories to be mentioned.
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist*Please* write to mailing lists, not to me
Re: Built header in different dir?
On Mar 30, 2001, Lars Hecking [EMAIL PROTECTED] wrote:
Or is it just as simple as
file.o: ../header.h
in subdir/Makefile.am?
This should work.
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist*Please* write to mailing lists, not to me
Re: program target missing $(EXEEXT)
On Mar 28, 2001, "Robert Collins" [EMAIL PROTECTED] wrote:
From: edward [mailto:[EMAIL PROTECTED]]
development utilities like libtool *expect* the .exe to *not* be
explicitly tagged in the Makefiles. having .exe breaks libtools
usage of scripts to wrap applications which need a loader hint
This is a correct assessment. Maybe libtool should give up on
creating wrapper scripts, and start linking replacement executables
with similar effects?
Isn't there a _SCRIPTS primary _for scripts_. That doesn't get
$(EXEEXT) added to it at all. Perhaps the wrong target was being
used?
Nope. automake can't tell in advance whether libtool will decide to
link the executable in-place or create a wrapper script.
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist*Please* write to mailing lists, not to me
Re: ok, new libtool for cygwin updates
On Mar 12, 2001, "Robert Collins" [EMAIL PROTECTED] wrote:
Well as CVS libtool (the point of the exercise :]) depends on CVS
automake CVS autoconf
Does it? It shouldn't. Are you sure?
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist*Please* write to mailing lists, not to me
Re: ok, new libtool for cygwin updates
On Mar 13, 2001, "Robert Collins" [EMAIL PROTECTED] wrote:
"The CVS version of GNU libtool often depends on some yet to be released
^
versions of GNU Autoconf and GNU Automake."
Just before the "Resources" section.
AFAIK, the current CVS version of libtool shouldn't depend on
unreleased versions of automake or autoconf, even though they might.
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist*Please* write to mailing lists, not to me
Re: 13-single-var-storage.patch
On Mar 9, 2001, Akim Demaille [EMAIL PROTECTED] wrote:
I should have built a independent automake.in to reconstruct a
cleaner patch, sorry.
Ever heard of interdiff?
http://people.redhat.com/twaugh/ftp/interdiff/stable/
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist*Please* write to mailing lists, not to me
Re: cross-install-strip summary
On Mar 5, 2001, Alexandre Duret-Lutz [EMAIL PROTECTED] wrote:
"Tom" == Tom Tromey [EMAIL PROTECTED] writes:
Tom What if we make install-strip unconditionally use install-sh? Do
Tom we really care about the small performance impact on a
Tom rarely-used target?
I don't. Maybe Alexandre does?
I don't either. Let's go for it.
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist*Please* write to mailing lists, not to me
Re: Why does make distclean rerun autoconf?
On Mar 5, 2001, Tom Tromey [EMAIL PROTECTED] wrote:
We use a rule that rebuilds Makefile if Makefile.in has changed. GNU
make will try to build `Makefile', if such a target exists, before
running any other target, including `distclean'.
Maybe we could convince the maintainer(s?) of GNU make to introduce an
extension: some way to mark certain targets as not requiring a
Makefile update.
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist*Please* write to mailing lists, not to me
Re: yaccvpath.test
On Feb 28, 2001, "Derek R. Price" [EMAIL PROTECTED] wrote:
CVS uses a single second sleep to guarentee timestamps change cross-platform
IIRC, FAT filesystems can only store even second numbers. So, in
order to be 100% safe, you'd need to sleep for 2 seconds, but a
1-second sleep should be ok on at least 50% of the cases.
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist*Please* write to mailing lists, not to me
Re: Manual additions (DOS issues)
On Feb 20, 2001, "Tim Van Holder" [EMAIL PROTECTED] wrote:
+case "$foo_dir" in
+ [\\/]* | ?:[\\/]) # Absolute
^ missing a `*' here, I suppose
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist*Please* write to mailing lists, not to me
Re: $ in source file names
On Feb 19, 2001, Robert Boehne [EMAIL PROTECTED] wrote:
I attempted to build a test case which uses a file with a $ in
the name.
Is this not supported by Automake, or is it a bug?
The former, I think.
If Automake doesn't support $ in source file names, then
I would suggest that it isn't an important requirement for Libtool.
I disagree. libtool can be used independently from automake. And, in
fact, until libtool supports correctly file names containing `$' and
line-feeds, I won't be convinced we do the right thing regarding
single-evaluation of arguments.
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist*Please* write to mailing lists, not to me
Re: Building shared libs as dynamically-loaded perl modules
On Feb 15, 2001, Jeremy Slade [EMAIL PROTECTED] wrote:
As I understand it, a 'convenience' library is intended for two
things: a static convenience lib is for linking into a program
(therefore it contains the non-PIC objects, *.o), and a shared convenience
lib is for linking into another shared lib (therefore it contains the
PIC objects, *.lo).
Yep. The latter is precisely what you seem to way.
So I think I want to install the MiscContrib 'convenience lib' to a
directory where it is accessible for ShapeUtils to link against.
Yep. I think it's time for libtool to start supporting the concept of
installable PIC static libraries. Meanwhile, here's something you can
try: link all the libtool objects that are part of MiscContrib into a
single libtool object file, and install that object file (does libtool
support installing object files? I don't recall for sure). Then,
link that libtool object into your libtool library.
The same thing applies for linking swigShapeUtils.sl
against libShapeUtils.a and libShapeUtils.sl.
But this is easier, because they're all in the same package.
Without libtool, this is all very easy to do -- albeit not easy to do
in a platform-independent way.
And that's the catch. On some platforms, you just can't link static
libraries into shared ones. Not even if they're PIC. Convenience
libraries, with the abstraction of ``aliases to sets of objects'',
should just work. It's just that they are not currently installable.
I wish they were. And I wish convenience libraries could still come
in PIC and non-PIC versions, just like object files. Currently, every
time you create a convenience archive, you don't get the non-PIC
objects, unless the PIC objects aren't available.
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist*Please* write to mailing lists, not to me
Re: automake 1.4d
On Feb 15, 2001, Tom Tromey [EMAIL PROTECTED] wrote:
ftp://tromey:[EMAIL PROTECTED]//gd/gnu/lib/config.guess
ftp://tromey:[EMAIL PROTECTED]//gd/gnu/lib/config.sub
These are available for anonymous ftp at ftp.gnu.org/pub/config.
Maybe so should the others?
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist*Please* write to mailing lists, not to me
Re: Building shared libs as dynamically-loaded perl modules
On Feb 14, 2001, Jeremy Slade [EMAIL PROTECTED] wrote:
It seems that what I really what is to create swigShapeUtils.sl
using the original ../../lib/*.lo files build earlier (and used to
create libShapeUtils.sl), rather than create swigShapeUtils.sl with
a run-time dependency on libShapeUtils.sl (which of course isn't
installed at the time I'm build swigShapeUtils.sl). In short, I
think I ultimately want:
ld -b -E -o swigShapeUtils.o swigShapeUtils.lo ../../lib/*.lo
and not
ld -b -E -o swigShapeUtils.o swigShapeUtils.lo -L../../lib -lShapeUtils
But how do I achieve that?
Create ShapeUtils as a libtool convenience library. If you also want
it to be installed as a separate shared library, you can create such a
separate shared library, naming the convenience library differently.
Ditto for MiscContrib.
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist*Please* write to mailing lists, not to me
Re: AM_CFLAGS
On Feb 12, 2001, Tom Tromey [EMAIL PROTECTED] wrote:
My understanding is that autoconf prevents us from putting these names
(AM_*) into configure.in.
We can remove specific items from autoconf's blacklist. Anyway, the
variables you mentioned are Makefile variables, not generally listed
in configure.in. What am I missing?
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist*Please* write to mailing lists, not to me
Re: AM_CFLAGS
On Feb 12, 2001, Steve Robbins [EMAIL PROTECTED] wrote:
And I thought that it was a simple bug: the aclocal regexp was not
taking into account the possibility of assigning to a variable name
starting with "AM_".
You shouldn't assign to these variables. These are for *users* to
override, not for configure.in to override. It's good that aclocal
and autoconf won't let you do it easily.
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist*Please* write to mailing lists, not to me
Re: AM_CFLAGS
On Feb 13, 2001, Tom Tromey [EMAIL PROTECTED] wrote:
I don't want to remove anything from autoconf's blacklist. Doing that
means we have to update autoconf whenever we change automake.
Nope. CVS Autoconf has a macro to remove strings from the blacklist.
ifdef([m4_pattern_allow],[m4_pattern_allow([AM_CFLAGS])])
will let you refer to AM_CFLAGS in configure.in without introducing
any dependency on CVS autoconf.
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist*Please* write to mailing lists, not to me
Re: Patch 3 of 4: Avoid 8+3 filename trouble
On Feb 10, 2001, "Tim Van Holder" [EMAIL PROTECTED] wrote:
* remake-hdr.am (@STAMP@): Use .T as suffix for the
temporary file.
You should probably patch autoconf's autoreconf too.
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist*Please* write to mailing lists, not to me
Re: AM_CFLAGS
On Feb 11, 2001, Tom Tromey [EMAIL PROTECTED] wrote:
In the recent namespace conversation we didn't mention macros like
`AM_CFLAGS'. This is an automake-specific macro which the user is
allowed to set.
How should we rename these?
Why should we rename these? Their names look fine to me.
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist*Please* write to mailing lists, not to me
Re: Small autoreconf patch (was Re: Patch 3 of 4: Avoid 8+3 filename trouble)
On Feb 11, 2001, "Tim Van Holder" [EMAIL PROTECTED] wrote:
* remake-hdr.am (@STAMP@): Use .T as suffix for the
temporary file.
You should probably patch autoconf's autoreconf too.
What part would need patching?
The one that choose stamp file names like those created by automake.
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist*Please* write to mailing lists, not to me
Re: autoconf bug?
On Feb 9, 2001, Tomas Berndtsson [EMAIL PROTECTED] wrote:
I don't see why I need that, but I tried, and it still didn't
work.
In this case, you may have found a bug in autoconf. The automake
mailing list is certainly not the best place to report an autoconf
bug :-)
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist*Please* write to mailing lists, not to me
Re: autoconf bug?
On Feb 8, 2001, Tomas Berndtsson [EMAIL PROTECTED] wrote:
My autoconf version is 2.13. m4 is GNU m4 1.4.
I have the following in my configure.in:
AC_CHECK_FUNCS(dlopen, , AC_CHECK_LIB(dl,dlopen, ,
[AC_MSG_ERROR([
*** Zen does not function properly without dlopen, sorry.])]))
You're missing quotes around [AC_CHECK_LIB(..)]
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist*Please* write to mailing lists, not to me
Re: Allow per-object cflags?
On Feb 9, 2001, Emil Ong [EMAIL PROTECTED] wrote:
prog1_SOURCES = prog.c
prog1_CFLAGS = -DPROG_NAME=\"prog1\"
prog2_SOURCES = prog.c
prog2_CFLAGS = -DPROG_NAME=\"prog2\"
This should work with CVS automake.
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist*Please* write to mailing lists, not to me
Re: Conditonnal
On Feb 8, 2001, "Florent. Devin" [EMAIL PROTECTED] wrote:
How can I make a Makefile based on automake to be conditionnal
at make time and not at configure time.
Basically, you can't. This just can't be done with portable Makefile
rules, in general.
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist*Please* write to mailing lists, not to me
Re: autotools + MSVC
On Feb 7, 2001, Geoffrey Wossum [EMAIL PROTECTED] wrote:
Command line error D2021 : invalid numeric argument '/Wp,-MD,.deps/applicationpr
I'm using automake 1.4
automake 1.4's ``development'' Makefiles (i.e., those you get before
`make dist' or `automake -i') require GNU make and GCC. CVS
automake's don't.
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist*Please* write to mailing lists, not to me
Re: AM_INCLUDE is a bad name.
On Feb 6, 2001, Akim Demaille [EMAIL PROTECTED] wrote:
Don't go that way! AC_PREREQ.
It won't let you define fallbacks for older releases, which is exactly
the point. ifdef, as you proposed, is the way to go.
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist*Please* write to mailing lists, not to me
Re: AM_INCLUDE is a bad name.
On Feb 5, 2001, Tom Tromey [EMAIL PROTECTED] wrote:
I'd like to also work out a naming scheme for internally generated
targets. That way eventually it will be clear what people can rely on
and what they cannot. Suggestions here are welcome.
How 'bout `_am-target-name'? (note the leading underscore)
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist*Please* write to mailing lists, not to me
Re: 31-ac-libsources.patch Re: amtraces
On Feb 5, 2001, Akim Demaille [EMAIL PROTECTED] wrote:
* tests/semantics.at (AC_REPLACE_FUNCS): New test.
* acfunctions.m4 (AC_REPLACE_FUNCS, _AC_LIBOBJ_ALLOCA): Use
AC_LIBSOURCES.
Ok
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist*Please* write to mailing lists, not to me
Re: Uppercasing files
On Jan 31, 2001, Emiliano [EMAIL PROTECTED] wrote:
Tom Tromey wrote:
Write explicit rules.
SOMETHING.EXT: something.ext
Yes, but I'd rather not if it can be avoided.
I'm afraid it can't. Unix is case-sensitive, why shouldn't `make' be?
Well... I suppose you could do something about it if you were willing
to get your Makefiles non-portable and use GNU make only, by using
$(shell ) magic. Or you could write a script to generate the rules
and get them included in the Makefile with AC_SUBST_FILE or automake's
include feature.
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist*Please* write to mailing lists, not to me
Re: maintainer-check
On Jan 31, 2001, Tom Tromey [EMAIL PROTECTED] wrote:
Could you fix these?
I guess this was an implicit Ok for his 16-maintainer-fixes.patch :-)
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist*Please* write to mailing lists, not to me
Re: Linking with installed libtool-constructed library
On Jan 29, 2001, Steve Robbins [EMAIL PROTECTED] wrote:
There is a patch for "automake" in the CVS libtool README.
Apart from that, are there any things I need to look out for,
if I mix CVS libtool with the released automake and autoconf?
Not AFAIK.
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist*Please* write to mailing lists, not to me
Re: Linking with installed libtool-constructed library
On Jan 28, 2001, Steve Robbins [EMAIL PROTECTED] wrote:
libtool --mode=link gcc -o foo foo.o /usr/local/libbar.la
(rather than just "gcc ... -lbar"). This allows libtool a chance to
do special stuff.
So, what's the recommended way of making this happen?
Use a CVS version of libtool and it will do The Right Thing (TM).
Except at `configure' time, because AC_CHECK_LIB doesn't use libtool.
Perhaps it should?
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist*Please* write to mailing lists, not to me
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
Re: automake - libtool - lib.so - lib.a
On Jan 25, 2001, Franois Chenais [EMAIL PROTECTED] wrote:
I would like to make a lib.so library with an other static lib2.a library
but I have
*** Warning: inter-library dependencies are not known to be supported.
Get CVS libtool and hope the platform(s) of your choice support
linking static libraries into shared libraries. This is not generally
supported, and some platforms will still get this kind of message, but
it just can't be done in general.
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist*Please* write to mailing lists, not to me
Re: Automake shooting in its foot
On Jan 24, 2001, Akim Demaille [EMAIL PROTECTED] wrote:
"Alexandre" == Alexandre Oliva [EMAIL PROTECTED] writes:
Alexandre Meanwhile, can't we just hide the uses of AC_PROG_CC and
Alexandre _CXX from automake by adding ][ in the middle of their
Alexandre names?
Right, but the code is already so hairy that I wondered whether I
wanted to add more crap into it. If you think it's OK
I think it's ok. But I agree the code is messy. We need
AC_HOOK(MACRO, BEFORE, AFTER) in autoconf.
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist*Please* write to mailing lists, not to me
Re: Automake shooting in its foot
On Jan 24, 2001, Akim Demaille [EMAIL PROTECTED] wrote:
"Alexandre" == Alexandre Oliva [EMAIL PROTECTED] writes:
Alexandre I think it's ok. But I agree the code is messy. We need
Alexandre AC_HOOK(MACRO, BEFORE, AFTER) in autoconf.
Wow! This sounds real hard, or at least, really expansive if we do
for all the macros. I was thinking of hooks for AC_PROG_CC and the
like.
Expensive?
AC_DEFUN([AC_HOOK],[define([$1], [$2]defn([$1])[$3])])
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist*Please* write to mailing lists, not to me
Re: Automake shooting in its foot
On Jan 24, 2001, Akim Demaille [EMAIL PROTECTED] wrote:
So to run a hook you need to insert something *inside* the pro/epi
pair.
Only if the macro is AC_DEFUNed. In which case, we might attempt to
match pro/epi in the defn and insert the hooks before/after the actual
DEFUN, i.e., between pro and epi.
Finally, let me state things clearly: I'm doing this to help people
proceed with their bad habits, but from the beginning I was against
hooking on AC_PROG_CC etc.
It was the only way to achieve a design decision in automake
(automatic dependency tracking) and libtool (automatic compiler
configuration). Sorry you didn't like it. But unless autoconf
supplies clean manners to do what is needed, people (myself included,
or should I say especially myself) will find ways around the
limitations.
In fact, I am still against generic hooks because that's a bad thing
to do. Nobody where ever imagine doing this in another programming
language.
Except those insane folks that came up with OO, right? :-)
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist*Please* write to mailing lists, not to me
Re: Automake shooting in its foot
On Jan 24, 2001, Akim Demaille [EMAIL PROTECTED] wrote:
"Alexandre" == Alexandre Oliva [EMAIL PROTECTED] writes:
Alexandre In which case, we might attempt to match pro/epi in the
Alexandre defn and insert the hooks before/after the actual DEFUN,
Alexandre i.e., between pro and epi.
Oh, just that? ;)
I have no idea whether it's hard to do.
Worst case, we can break AC_DEFUNed macros into two macros, one with
the actual name, that contains the prologue and the epilogue and,
between them, an invocation of another macro, containing the actual
code. Then, hooking something before or after a pro/epi macro would
be just a matter of pre/appending the code to this other macro.
I understand the goal was noble and user oriented. But I find it
extremely dangerous.
Point taken. We have to be careful not to break it. So far, it's
worked moderately well. The good thing is that, when they break,
people notice it immediately.
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist*Please* write to mailing lists, not to me
Re: More an autopackage
On Jan 22, 2001, Michael Sweet [EMAIL PROTECTED] wrote:
What it doesn't do (yet) is provide a tool to automate the creation
of the list file.
make install DESTDIR=/tmp/install
find /tmp/install/. ! -name . -print | sed 's,^/tmp/install,,'
rm -rf /tmp/install
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist*Please* write to mailing lists, not to me
Re: Automake shooting in its foot
On Jan 23, 2001, [EMAIL PROTECTED] wrote:
So, IMHO, we have just no issue until we release an autoconf --trace
aware automake. And frankly, I can't wait :) Automake will be much
shorter (less hard coded knowledge on Autoconf), more robust (less
hard coded knowledge on Autoconf), and more extendible (less hard
coded knowledge on Autoconf).
:-)
Meanwhile, can't we just hide the uses of AC_PROG_CC and _CXX from
automake by adding ][ in the middle of their names?
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist*Please* write to mailing lists, not to me
Re: make check prerequisites
On Jan 22, 2001, Lars Hecking [EMAIL PROTECTED] wrote:
I'm looking for a way to run a specific target before check-TESTS.
check: your-target
your-target:
do whatever you want
If you really mean check-TESTS, use that instead of check.
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist*Please* write to mailing lists, not to me
Re: make install-strip in cross-compilation environments
On Jan 18, 2001, Tom Tromey [EMAIL PROTECTED] wrote:
Alexandre We could surely adjust install-sh so as to take a STRIP
Alexandre variable into account, and set INSTALL_STRIP (a new
Alexandre variable, set to the same as `$(INSTALL)' if not
Alexandre cross-compiling, or to `STRIP=toolchain-strip
Alexandre $(CONFIG_SHELL) /path/to/install-sh' otherwise) in the
Alexandre configure script.
install-sh already supports STRIPPROG.
The problem arises when using the vendor (even GNU) install.
Even better! Then we can just arrange for INSTALL_STRIP to set
STRIPPROG and use install-sh for cross install-strip. install-strip
would pass INSTALL=$(INSTALL_STRIP) to the sub-make, where
INSTALL_STRIP would be set by configure as needed for cross builds.
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist*Please* write to mailing lists, not to me
Re: More an autopackage
On Jan 18, 2001, David Lee [EMAIL PROTECTED] wrote:
On Thu, 18 Jan 2001, Geoffrey Wossum wrote:
1) written in Python
Wouldn't Perl5 be a more widely acceptable choice? Considerably so?
(Indeed, isn't automake already in Perl? Why choose something different?
Especially when that something is considerably less widely installed?)
Because Perl is almost unreadable and Python is a very nice language?
6) When I get going with Actual Code (TM) (within a couple of weeks),
I'll setup a project on sourceforge for this.
No promises. But I could try to have a quick look at Solaris pkgadd/pkgrm
issues once you have got started.
One may find a lot about packaging for native systems in the Samba CVS
tree. See www.samba.org.
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist*Please* write to mailing lists, not to me
Re: echoing command lines
On Jan 14, 2001, Ben Elliston [EMAIL PROTECTED] wrote:
Is there a workaround?
LIBTOOL="/path/to/libtool --silent"
Perhaps automake should introduce support for LTFLAGS?
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist*Please* write to mailing lists, not to me
Re: Automake: Compiling sources in other directories
On Dec 15, 2000, Dave Brolley [EMAIL PROTECTED] wrote:
The problem is that h1.o is in the 'main' subdirectory along with all of the
other object files. What's the right way to build a few sources from another
directory into an application?
Which version of automake are you using? Building sources from other
directories is only supported in CVS versions of automake.
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist*Please* write to mailing lists, not to me
Re: rpath command?
On Nov 22, 2000, Marc van Woerkom [EMAIL PROTECTED] wrote:
automake should define it to `$(LIBTOOL) $(CC/CXX)...'. Maybe it only
does this when there is at least one source file to compile in the
current directory?
Bingo!
Makefile.am:
libSciFacBase_la_SOURCES = \
buildme.c
And you'd be surprised at the number of problems you'd encounter if
you didn't link at least one object file into a library.
buildme.c:
/* void do_really_nothing_useful() { } */
This is not a valid C program. A C program must contain at least one
valid declaration. Try something like `static int i;'
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist*Please* write to mailing lists, not to me
Re: texinfo.tex
On Nov 13, 2000, "Derek R. Price" [EMAIL PROTECTED] wrote:
"Derek R. Price" wrote:
Why does AM require that texinfo.tex be included in the distribution in
the first place? It is installed with tex distributions by default
anyhow, isn't it? Its presence screws up my PDF target, which needs to
Okay, I found the no-texinfo.tex option to disable this behavior,
but is there any reason this is ever desirable?
Not all distributions of TeX include the latest texinfo.tex. Or, at
least, there was a time when this was the case. Besides, as you say,
texinfo.tex is part of the texinfo package, which is separate from TeX
distributions, so just assuming TeX would be able to find may not work
for a significant number of users.
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist*Please* write to mailing lists, not to me
Re: More fun with BUILT_SOURCES
On Nov 14, 2000, Braden McDaniel [EMAIL PROTECTED] wrote:
I realize that BUILT_SOURCES is known to be problematic, but I haven't
found any other solution. Any suggestions?
Add explicit dependencies on it. There's no other way to ensure it's
generated. BUILT_SOURCES used to work only with GNU make.
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist*Please* write to mailing lists, not to me
Re: Fix for script magic.
On Nov 1, 2000, François Pinard [EMAIL PROTECTED] wrote:
[Pavel Roskin]
From Autoconf documentation:
If you omit the space before the path, then 4.2BSD based systems
(such as Sequent DYNIX) will ignore the line, because they interpret
`#! /' as a 4-byte magic number.
Let's remove that comment, as well as all those useless spaces.
They're not *totally* useless. The problem, IIRC, was that `file'
would only recognize shell scripts when they had the space in.
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist*Please* write to mailing lists, not to me
Re: PATCH: patsubst support
On Oct 27, 2000, Akim Demaille [EMAIL PROTECTED] wrote:
Yep, by default Automake must not let the users do nonportable
things.
I tend to agree. But I wouldn't say `must not', I'd say `should not'.
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist*Please* write to mailing lists, not to me
Re: Need help !
On Oct 26, 2000, Thomas Nagler [EMAIL PROTECTED] wrote:
Using the Makfile.am below starts in compiling the files without
doing sysdep before. Therefore they miss sysdep.inc and sysdep.h files.
Add to Makefile.am the line:
$(libgetorb_a_OBJECTS) $(getorb_OBJECTS): sysdep.h sysdep.inc
Maybe I do not use BUILT_SOURCES in the right way or I do misunderstand
the automake 1.4 manual.
One thing you're doing that probably conflicts with the way automake
deals with BUILT_SOURCES is that:
sysdep.h: sysdep Makefile
./sysdep
sysdep.inc: sysdep Makefile
./sysdep
the generated files depend on Makefile. IIRC, automake arranges (or
used to arrange) for Makefile to depend on $(BUILT_SOURCES), to make
sure they're up-to-date whenever something else is built (as long as
you use GNU make, that implicitly considers Makefile a target). So,
you've got a cycle in the dependence graph, and some arc gets dropped.
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist*Please* write to mailing lists, not to me
Re: automake compliance
On Oct 24, 2000, Dmitri Shparber [EMAIL PROTECTED] wrote:
I just have a question regarding automake utility. Is this utilitie
compliant with 64 bit architecture machines running on win2K platform?
What do you mean? automake is just a perl script.
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist*Please* write to mailing lists, not to me
Re: [PATCH] Fix for CRLF problem
On Oct 20, 2000, Akim Demaille [EMAIL PROTECTED] wrote:
This looks fine to me. Any resistance?
Ok with me.
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist*Please* write to mailing lists, not to me
Re: PATCH: depcomp cpp method output
On Oct 17, 2000, Akim Demaille [EMAIL PROTECTED] wrote:
| 2000-06-21 Alex Hornby [EMAIL PROTECTED]
|
| * depcomp: Altered sed clause to strip of inclusion depth
| numbers generated by cpp. Also output in gcc style.
Fine with me. Any objection?
Nope.
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist*Please* write to mailing lists, not to me
Re: Dependency tracking
On Oct 17, 2000, "Paul F. Kunz" [EMAIL PROTECTED] wrote:
Is there a way to allow the gcc developer to use automake dependency
tracking, while the other developer uses some other system.
Use CVS automake. It's dependency tracking mechanism no longer
depends on GNU make nor GCC.
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist*Please* write to mailing lists, not to me
Re: Avoiding cross-dependencies for aclocal.m4
On Oct 16, 2000, Akim Demaille [EMAIL PROTECTED] wrote:
This guy looks good to me. Any objection?
Nope.
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist*Please* write to mailing lists, not to me
Re: [PATCH] Dependency tracking for Microsoft Visual C/C++
On Oct 16, 2000, Akim Demaille [EMAIL PROTECTED] wrote:
| Hi,
| this patch implements support for extracting dependency tracking
| information by using the preprocessor mode of the Microsoft Visual
| C/C++ compiler.
Thanks, installed.
Could someone explain to me why we launch it in background and then
just wait for it to complete?
We compute dependencies in parallel with the actual compilation, but
we mustn't consider the job done before both are complete.
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist*Please* write to mailing lists, not to me
Re: [PATCH] compare header files before installing
On Oct 16, 2000, Akim Demaille [EMAIL PROTECTED] wrote:
This patch seems OK to me, but I'd appreciate if Alexandre, Tom, Pavel
or Jim could confirm it's OK.
I have mixed feelings about this. At first, it may sound nice to not
touch pre-existing files. However, think of someone that uses the
timestamp to decide whether a certain file is part of the newly
installed package or just some remnant from an old release that can
now be removed...
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist*Please* write to mailing lists, not to me
Re: project link problems
On Oct 12, 2000, Josh Steiner [EMAIL PROTECTED] wrote:
Now my file gets built, i can use preprocessor definitions from
those files, but when i try to call a function (foobar) from one of
those files (tX_middin.cc/h) i get an error in linking.
Make sure `foobar' is declared as `extern "C"' if it is defined in C
but called from C++.
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist*Please* write to mailing lists, not to me
Re: Libraries within the same package
On Sep 9, 2000, Simon Richter [EMAIL PROTECTED]
wrote:
One of my packages comes with a shared library and a program that should
link against it. How can I tell automake to link against a not-yet-built
library and set a proper -rpath in the executables (i.e. one that points
to @libdir@)?
automake can't do it, but libtool (that automake knows how to use) can.
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist*Please* write to mailing lists, not to me
Re: VPATH in automake
On Sep 8, 2000, James Bonfield [EMAIL PROTECTED] wrote:
automake: Makefile.am: not supported: source file `a/a.c' is in subdirectory
This is supposed in CVS automake.
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist*Please* write to mailing lists, not to me
Re: [patch] new depcomp sxc method
On Sep 6, 2000, Bernard Dautrevaux [EMAIL PROTECTED] wrote:
This patch is quite simple as the preprocessor is able to generate directly
the correct dependency file with dummy dependencies for all included files
to avoid the "deleted header file" syndrom.
It would be nice to note this fact as a comment in the script,
otherwise someone unaware of this fact might think of ``fixing'' it
later on :-).
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist*Please* write to mailing lists, not to me
Re: Automake Bug?
On Aug 27, 2000, "W. Reilly Cooley, Esq." [EMAIL PROTECTED] wrote:
Now, maybe I'm misunderstanding Make's macro-passing, but in order for
the DESTDIR passed to the make in the first place, doesn't the @$(MAKE)
line need something like 'DESTDIR=$(DESTDIR)' ? Would this be the
correct way to fix this?
AFAIK, POSIX-compliant implementations of `make' should pass down to
sub-makes any variables set in the command-line of the top-level make.
GNU make, for example, does this, so DESTDIR works as expected.
But automake could indeed pass it down explicitly, to support other
makes in this regard.
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist*Please* write to mailing lists, not to me
Re: Automake + file.in
On Aug 17, 2000, "Nikolaus Kimmel (FT3/AB Ulm)" [EMAIL PROTECTED]
wrote:
So how can I put variables (in which syntax) into the AC_OUTPUT command,
so that automake don't give me errors.
You can't. Automake requires static knowledge of all AC_OUTPUT files.
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist*Please* write to mailing lists, not to me
Re: Multiple libtool libs from same sources
On Aug 2, 2000, Adam C Powell IV [EMAIL PROTECTED] wrote:
Adam C Powell IV wrote:
Greetings,
I'd like to build two libtool libs from the same sources using different
CFLAGS.
Okay, I assume the lack of reply means it can't be done.
IIRC, CVS automake supports libfoo_la_CFLAGS
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist*Please* write to mailing lists, not to me
Re: [Re: Shared library with source in sub directories]
On Jul 16, 2000, Tom Tromey [EMAIL PROTECTED] wrote:
Murray 1) This doesn't work recursively. For instance, if sub
Murray contains, subsub, which contains subsusbsub, then the library
Murray at sub will contain subsub but not subsubsub. Therefore you
Murray have to LIBADD all the libraries in the top makefile.
This is suprising. I thought this was one of the benefits of libtool
-- portable library dependencies.
It depends on which version of libtool you're using. IIRC, libtool
1.3.5 (the latest release) still doesn't fully support inter-library
dependencies. 1.4-to-be (CVS trunk) is supposed to fix this problem.
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist*Please* write to mailing lists, not to me
