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
x27;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.
g' 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 [EMA
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 s
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 i
[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-st
C, the GNU
Coding Standards suggest that programs should be built with debugging
information, unless the user explicitly requests otherwise.
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD
On Jun 20, 2001, Tom Tromey <[EMAIL PROTECTED]> wrote:
>>>>>> "Alexandre" == Alexandre Oliva <[EMAIL PROTECTED]> writes:
Richard> With separate Makefile.am's in each directory,
Richard> automake should be able to figure the bar/foo out from
Ric
lso 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.o
On Jun 19, 2001, Tom Tromey <[EMAIL PROTECTED]> wrote:
>>>>>> "Alexandre" == Alexandre Oliva <[EMAIL PROTECTED]> writes:
>>> I was thinking I could create a new `patch' category in the automake
>>> Gnats and ask people to put such
thers 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 co
.
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 stud
hich 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.
--
A
ly 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
, so that the user can override the
setting of prefix, exec_prefix, etc, during `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.un
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
ificant amount of time on slow platforms.
--
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
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&
gure-time tests that
few people would use (I generally prefer to defer to `missing'), and
then, we'd be running a shell-script anyway, and we wouldn't be able
to cache results, unless we came up with some way for missing to cache
results of tests.
--
Alexandre Oliva Enjoy Guarana
On May 28, 2001, "Maciej W. Rozycki" <[EMAIL PROTECTED]> wrote:
> On 26 May 2001, Alexandre Oliva wrote:
>> > Note that I'm writing of a performance. Install-sh is a serious
>> > performance hit for non-trivial installs.
>>
>> How about
e found in the PATH or not, and only
report its warning if it finds the program is indeed 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.i
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 instal
ll 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.
, 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*Plea
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.
7;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
on
> the build system, or something else?
Yep. The idea is that the distribution should include the generated
info files, so that random installers won't need texinfo to install
the info documentation. They're placed in the source tree so that
a maintainer set-up doesn't differ fr
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-Unic
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.
On May 6, 2001, Tom Tromey <[EMAIL PROTECTED]> wrote:
> `1.4.1' is an alpha release by our rules.
I thought only releases ending in letters were alpha.
There's always 1.4p1.
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliv
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.
> :
>
nd I would like configure to detect if mylib
> is not installed.
For libraries, add -Ldirectory to LDFLAGS.
> I prefer not to put it in an environnement variable.
You're out of luck, then.
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC De
directory.
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.
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.c
ymlinks would break `make dist'. What is the symptom?
--
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 Evang
On May 2, 2001, François Chenais <[EMAIL PROTECTED]> wrote:
> While using configure under sparc-sun-solaris2.6, it choose the option
> -MD for cc but this one doesn't know about this option.
Which version of automake?
--
Alexandre Oliva Enjoy Guarana', see http://ww
On Apr 27, 2001, <[EMAIL PROTECTED]> wrote:
> test_md5_SOURCES = test_md5.c profile_md5.c
> test_md5_LDADD = md5.o
How about:
test_md5_SOURCES = test_md5.c provfile_md5.c
nodist_test_md5_SOURCES = md5.c
# requires CVS automake
md5.c:
$(LN_S) /path/to/md5.c md5.c
-
does indeed work.
Huh? Even though it's a shell-script? This would be very good news.
>> Who's to blame, libtool or automake?
Libtool.
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{c
n 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
e 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
h
lawyer could say is that it's risky to use it. That's why it's so
important that the authors of the work clearly state the terms under
which they intend their work to be used. Then, legal counsel might
have something useful to say.
--
Alexandre Oliva Enjoy Guarana', see http
racking 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
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
ly 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
fore
>> 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-U
EXT)
> 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
ILT_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.
gure 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.uni
y encoded in the Makefile, except for BUILT_SOURCES, that
automake takes care of building by itself.
--
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@
> 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
f 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
On Apr 6, 2001, Raja R Harinath <[EMAIL PROTECTED]> wrote:
> Hi,
> Alexandre Oliva <[EMAIL PROTECTED]> writes:
>> On Apr 5, 2001, Raja R Harinath <[EMAIL PROTECTED]> wrote:
>> > The problem is that 'automake' now depends on the AC_SUBSTs in
>
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/
R
#x27;s, it does not see the
> actual definition of AM_INIT_AUTOMAKE (autoconf bypasses the 'aclocal'
> mechanism). Here's a patch to autoconf to fix this.
I'm afraid patching aclocal.m4 won't help much, since it's a generated
file.
--
Alexandre Oliva Enjoy Guaran
On Apr 5, 2001, Adam C Powell IV <[EMAIL PROTECTED]> wrote:
> By the way, how do I unsubscribe?
See the `List-Unsubscribe' header in every message you receive.
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer
(in case of name collisions.
There's an automake option that tells it to keep object files in
subdirs. I don't recall the exact spelling.
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com
s 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* wri
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
) 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 Develop
If it doesn't work with them, I think we're out of luck :-(
--
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
:
prog=$1
shift
$prog ${1+"$@"} && exit 0
?
--
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
ut this problem in an RPM-specific
forum.
--
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
message will be highlighted in
my mailing-list folder. Those who would rather not be Cc:ed should
configure their mailers so as to add a header `Mail-Copies-To: never'
to messages they post to mailing lists.
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.uni
; 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
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.unic
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://
nce 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 stud
> 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-Unicamp
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 Ev
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
> Can libtool handle such a situation?
It's supposed to, yes.
--
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 So
> 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
singl
on 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&#
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 O
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.
fdef([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, redha
reversed :-(
I suppose automake should remove AM_CFLAGS et al from autoconf's
blacklist, then.
--
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@{l
se 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.c
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 Evangelis
he 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 Sof
e? 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
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.
other targets, parallel builds may lose.
--
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
such
> architectures the .o files must be specially built (eg with PIC).
Right. Libtool can only build libtool libraries from libtool objects
and other libtool libraries.
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer
On Feb 9, 2001, Tomas Berndtsson <[EMAIL PROTECTED]> wrote:
> The autoconf online manual says bugs should go to
> [EMAIL PROTECTED], but that seems like a pretty old and
> possibly outdated address (no @gnu.org address). Is there a better
> one?
[EMAIL PROTECTED]
--
Alexa
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 :-
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.
--
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
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, gn
use
its new features. AC_VERSION_CASE would be a good thing in this case.
Ditto for libtool. And for any other tool that wants to impose as
little as possible onto its users.
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{c
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.or
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.unicam
-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*
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.i
7; 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 fe
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.c
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.
--
Alexan
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 a
27;t set
${MAKE}. This would probably get us rid of the problem without losing
any functionality, since it's unlikely that a MAKE that doesn't set
MAKE sets MAKEFLAGS.
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{c
ts a newer timestamp than stamp-h3.
--
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
1 - 100 of 228 matches
Mail list logo
