Re: AM_CFLAGS

[Steve Robbins]

On Tue, Feb 13, 2001 at 01:14:31AM -0200, Alexandre Oliva wrote:
> 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.

Hm.  I didn't check the archives, but I'm pretty sure this discussion
has already taken place on at least one of the two auto* lists.

My recollection of that discussion was just the opposite: the user
gets to set CFLAGS, LDFLAGS, and the like, while the software author
gets to set AM_-versions of them.  Otherwise, why have two versions
of them?

Cheers,
-Steve

Re: Linking with installed libtool-constructed library

[Steve Robbins]

On Sun, Jan 28, 2001 at 06:19:08PM -0200, Alexandre Oliva wrote:
> 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).

Aha, yes it does.  Cool!


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?

-S

___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool

Linking with installed libtool-constructed library

[Steve Robbins]

Hello,

I have a project that uses automake & autoconf to build a program.
This program links against several previously-installed libraries.
One of these libraries was built by libtool.

The libtool docs (I'm working with libtool 1.3.5) suggest that one ought to 
link using

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?  

The library in question is optional, and configure detects its
presence automatically with AC_CHECK_LIB and the like.  But this only
checks whether a program links properly using "-lbar", and does not
give me the pathname of the ".la" file, of course.

I checked the autoconf macro archive 
but found nothing suitable.  I looked at the libtool mailing list archives
briefly, and didn't find any answer.  I did find someone proposing something
that sounds like a solution:



The solution I would like to see is to supply AC_CHECK_LTLIB
macro with libtool.  The macro first looks for installed libtool
libraries and assign /path/to/libfoo.la to the appropriate
variable.  It should fallback to AC_CHECK_LIB compatible mode
(looks for libfoo.so and exports `-L/path/to` and `-lfoo`), in
case libtool library is not found.

This person later posted the start of an implementation, 
 but there was
no discussion that I could see.

What I ended up doing is writing some shell code in "configure" that
filters the "$LIBS" variable, replacing "-lbar" with "/path/to/bar.la", if
that file can be found in directories specified by "-L" options.  The 
code is a quick hack, but it works in limited cases (e.g. I only check for
static libs).

The configure snippet is shown below.  Is there a better way?

--- snippet of configure.in ---

dirlist=
newlibs=
proc_libs=no
for x in $LDFLAGS -- $LIBS; do
case $x in
-L*) dir=`echo $x | sed 's/^-L//'`
 dirlist="$dirlist $dir"
 ;;
-l*) lib=`echo $x | sed 's/^-l//'`
 for dir in $dirlist; do
if test -r $dir/lib${lib}.a -a -r $dir/lib${lib}.la; then
x=$dir/lib${lib}.la
fi
 done
 ;;
esac
if test $proc_libs = yes; then
newlibs="$newlibs $x"
elif test $x = --; then
proc_libs=yes
fi
done
LIBS=$newlibs

---

Thanks,
-Steve

Re: More an autopackage

[Steve Robbins]

On Mon, Jan 22, 2001 at 09:49:04PM -0500, Michael Sweet wrote:
> Rusty Ballinger wrote:
> > ...
> > (What packaging systems only let you create packages as root, and
> > why do they do that?  I know rpm *wants* you to be root, but you
> > don't have to be...)
> 
> Debian's dpkg needs you to run as root; otherwise the files you
> install will be owned by your user & group.
 
Paraphrasing Rusty Ballinger, dpkg "wants" you to be root,
but you can fake it.  I regularly build packages as a non-privileged
user.  The LD_PRELOAD tricks that "fakeroot" plays will 
result in a tarfile full of "root-owned" files.


-Steve

Re: rpath command?

[Steve Robbins]

On 27 Nov 2000, Alexandre Oliva wrote:

> On Nov 25, 2000, Tom Tromey <[EMAIL PROTECTED]> wrote:
> 
> >>> Do I have to use some macro in configure.in to fill $(LINK) with GNU ld?
> Alexandre> automake should define it to `$(LIBTOOL) $(CC/CXX)...'.
> Alexandre> Maybe it only does this when there is at least one source
> Alexandre> file to compile in the current directory?
> 
> > Yeah, that's how it works.  I realize this is less than good.  Can you
> > suggest how it ought to work?
> 
> I think the current behavior is fine, since it is indeed invalid to
> create a library or libtool archive out of no source files.  However,
> we might output a warning (or even an error) if we find a request to
> create a library out of no source files.

I'm not so sure about this.  Unless the CVS versions of the tools have
changed things, the current behaviour makes it impossible to create a
library consisting only of sources in subdirectories.  What I would like
to do is:

lib_LTLIBRARIES = libfoo.la

libfoo_la_LIBADD = \
$(top_builddir)/a/adummy.la \
$(top_builddir)/b/bdummy.la \
$(top_builddir)/c/cdummy.la \
$(top_builddir)/d/ddummy.la 


but this fails, so I generally add:

libfoo_la_SOURCES = dummy.c
dummy.c:
touch dummy.c


To me, the last bit seems like a workaround for a bug.  Is it impossible
to support building libraries out of ONLY other libraries?

-S

Link to searchable archive (was: cleaning in conditional subdirs)

[Steve Robbins]

Hello,

I had a question about automake, and discovered that there is no searching
facility at mail.gnu.org.

On Sun, 5 Nov 2000, Steve Robbins wrote:

> [Apologies if this has been covered before -- I couldn't figure out how to
> search the list archives at http://mail.gnu.org/mailman/listinfo/automake.]

Then I found some old notes which led me to another archive of this list,
but with a search tool.  

It would be a great service to your list participants if you could include
a link from the automake list archive page to this searchable one:

http://sources.redhat.com/ml/automake/

[Ditto for the autoconf list: http://sources.redhat.com/ml/autoconf/]


Thanks,
-Steve

P.S.  Perhaps there is a plan to include a searchable index of the GNU
list archives.  Unless you are going to set it up in the next five
minutes, it is still desirable to include a link (albeit temporarily) to
the redhat site.

cleaning in conditional subdirs

[Steve Robbins]

Hi,

I just ran into some "surprising" behaviour.

[Apologies if this has been covered before -- I couldn't figure out how to
search the list archives at http://mail.gnu.org/mailman/listinfo/automake.]


The situation is (and I double-checked that it persists with CVS automake
and autoconf) with a Makefile.am and conditionally-defined SUBDIRS, e.g.

if USE_B
SUBDIRS = a b
else
SUBDIRS = a
endif

Now, suppose "USE_B" is false.  

Of course, configure.in lists b/Makefile in AC_OUTPUT, so b/Makefile is
generated.  

The variable SUBDIRS is defined as "a" alone, so all rules but one do NOT
descend into subdir "b" (the exception is "make distdir").

This means that the sequence
./configure
make distclean

which one expects (after a fresh unpacking of the .tar.gz) to be a no-op,
will in fact create the file b/Makefile.


Now, on the face of it, an obvious remedy seems to be that all the "make
clean" family (clean,distclean,maintainer-clean) of rules should descend
into all possible subdirs, as does the "distdir" rule.

Would that be correct?  Are there drawbacks?

Thanks,
-Steve

Re: Automake security problem

[Steve Robbins]

On 2 Mar 2000, Alexandre Oliva wrote:

> On Mar  2, 2000, Jim Meyering <[EMAIL PROTECTED]> wrote:
> 
> > Alexandre Oliva <[EMAIL PROTECTED]> wrote:
> > | On Mar  1, 2000, Jim Meyering <[EMAIL PROTECTED]> wrote:
> > |
> > | > Don't use `ln' (which was just a space optimization anyway)
> > |
> > | A worthwhile optimization, IMO.
> 
> > Worthwhile?  Why?
> 
> Because then `make dist' is much faster.  I often find myself running
> `make dist' multiple times on packages I don't manage alone, to
> compare it with the source tree and see if somebody forgot to add some
> file to the dist rules.  I really appreciate that `make dist' is fast
> in this case.  But then, I often configure on another filesystem, so
> the `ln' optimization doesn't apply that often.
> 
> But I remember a posting, some time ago, from someone who was really
> glad about being able to fix errors in the dist tree and having them
> automagically fixed in the source tree too. 

That was me.  This helped me because the `maintainer' makefiles didn't
work with my non-gcc compiler.  Most of the development was done using
gcc, but in order to check that no GCC-isms had crept into the code, I
would occasionally `make distdir', and build the package in the distdir
with IRIX CC.  When I found a bug, it was nice that the edited source file
would show up in the distdir with no extra work.  Not a huge gain, but a
nice hack nonetheless.

Now, of course, dependency tracking works for IRIX CC, right?  So if the
optimization in question goes away, it will go away in a release of
automake that supports IRIX CC dep tracking, and I won't care too much.

-Steve