I've gone over and over the documentation, and browsed the mailing
list archives, but I'm not seeing what I'm looking for.
I have an application with two subdirectories, both of which contain
sources that will be made into shared libraries. In the /lib
directory, I make a single, standard share
automake-1.7.8/autoconf-2.57/libtool-1.5
in configure.ac (after all the libtool-related macros but before
AC_OUTPUT):
AM_CONDITIONAL(INSTALL_LIBS, test x$enable_shared = xyes)
in Makefile.am:
...
LIBLIST = src/lib/libnALFS.la
LIBLIST += src/handlers/alfs.la
LIBLIST += src/handlers/build.la
LIB
Gary V. Vaughan wrote:
Actually, you *do* need to install the libraries even if they are linked
into the program statically because libltdl looks up the pseudolibrary
(.la) in the module directory to get metadata about (even preloaded)
modules. Fixing this is on the TODO list, but it is quite
Gary V. Vaughan wrote:
Completely untested, but have you tried:
pkglib_LTLIBRARIES =
noinst_LTLIBRARIES =
if INSTALL_LIBS
pkglib_LTLIBRARIES += $(LIBLIST)
else
noinst_LTLIBRARIES += $(LIBLIST)
endif
Just tried it, same results, automake reports each module in LIBLIST
as "already going to be inst
Gary V. Vaughan wrote:
Argh! No wait, I am a dufus. A noinst_LTLIBRARY is always a convenience
library, whereas a pkglib_LTLIBRARY is affected by configure
--disable-shared etc. Even if you somehow got past the syntax problems,
the semantics are all wrong anyhow.
I'm not sure I follow all of
Gary V. Vaughan wrote:
Or, if you give the modules their own Makefile.am, you might be able to
redefine INSTALL and mkinstalldirs to neuter the install rules:
if !INSTALL_LIBS
INSTALL=:
mkinstalldirs=:
endif
That looks a lot more promising, I'll give it a try.
Gary V. Vaughan wrote:
Yeah, that is pretty sucky. What about installing the modules to a
bogus directory (in the build tree?) and then removing that directory?
if !INSTALL_LIBS
pkglibdir = $(top_builddir)/_noinst
install-exec-hook:
@echo "pruning statically linked modules"
Gary V. Vaughan wrote:
with the simpler:
~pkglibexec_LTLIBRARIES = gnu.la . traditional.la
~AM_LDFLAGS = -module
but unfortunately Automake wants to build `gnu.la' from `gnu.la.c', so the
repetitive sources declarations are necessary, unless I rename all my
source
files.
This would
Bob Friesenhahn wrote:
Please move the clean bug up in the priority level. Automake has a
non-recursive user now. :-)
More than one :-) My project also uses non-recursive Makefile to build a
bunch of libraries (one normal, about 30 plugin modules) and a couple of
other directories of executable
Bob Friesenhahn wrote:
My point was not entirely that the documentation was wrong. It is an
extremely useful capability to be able to define a common base set of
CPPFLAGS and then use per-target CPPFLAGS to extend these (equivalent
to +=). Otherwise the Makefile.am has to be very messy and large
Alexandre Duret-Lutz wrote:
(from automake-patches)
+ - Honor definitions in m4_included files. aclocal 1.8 had been
+updated to check m4_included files for new requirements, but
+forgot that these m4_included files can also provide new
+definitions.
+
+This principally affected
I'm trying to build the JOE editor (version 2.9.8) in a uClibc
buildroot. My buildroot has successfully built all the other stuff I
need, including some stuff I've added (device-mapper, LVM2, xfsprogs,
etc), that use GNU autotools for their build systems.
This packages uses a normal autotools b
Alexandre Duret-Lutz wrote:
Maybe you've used --target=i386-linux or something like this?
Yes, removing that solves the problems and does not cause any others.
Since this application is a "compiler", --build and --host are enough. I
was following the example of the existing Makefile fragments in
Alexandre Duret-Lutz wrote:
[...]
Kevin> I removed all three AC_CANONICAL_* macro calls before
Kevin> removing --target, but this did not seem to change
Kevin> anything.
[...]
Forgive me, but did you actually regenerate configure after
doing this? (Joe uses AM_MAINTAINER_MODE, which means thos
Michael Cook wrote:
Makefile.am: C source seen but `CC' is undefined
Makefile.am:
Makefile.am: The usual way to define `CC' is to add `AC_PROG_CC'
^
Makefile.am: to `configure.in' and run `autoconf' again.
$ autoconf
configure.in:3: err
Kevin P. Fleming wrote:
Gotta watch that typing :-)
Oh foo, my attempt to use fancy arrows failed...
You put in AC_PROC_CC, when it's supposed to be AC_PROG_CC. The original
error message had it spelled correctly, but the second one shows the
incorrect spelling.
Sander Niemeijer wrote:
As a general remark, automake is not that clear in the precedence that
compiler flags take (will FOOFLAGS come before or after
AM_FOOFLAGS/target_FOOFLAGS) and if/how one would be able to overrule
these flags. Important is also to notice that CXXFLAGS/CFLAGS or
overruled
17 matches
Mail list logo
