I have in configure.ac:
PKG_CHECK_MODULES([LIBXML2], [libxml-2.0 >= 2.6.26])
and I use $(LIBXML2_LIBS) in Makefile.am.
It works if libxml2 is linked dynamically, but now if it's static linking fails because of missing -lz.
A workaround for the user is to set
PKG_CONFIG="pkg-config --static"
but I'd rather enhance the configure script in such a way that this workaround is not necessary.
Of course I don't know if libxml2 will be static or DSO, so I can't just hardcode the --static flag. Anyone has a macro for this?
Update - the last comment in the above bug report shows that they addressed the problem by adding a new macro, PKG_CHECK_MODULES_STATIC. See also this commit.
This appears to be live in pkg-config versions > 0.29.
Using:
PKG_CONFIG="pkg-config --static"
seems to be the way to do it according to this pkg-config bug report.
Related
A user of xnec2c was trying to build on OSX and had autoconf issues because PKG_CHECK_MODULES could not be found since MacPorts puts it in a funny spot.
The user made autoconf work like so:
ACLOCAL_PATH=/opt/local/share/aclocal ./autogen.sh
ACLOCAL_PATH=/opt/local/share/aclocal ./configure
I would like to make it build on OSX without special user path hacks for ACLOCAL_PATH. Can that be done?
I started writing a possible fix below and realized it could an xyproblem so posed the question just above. However, if this starts any gears turning, then I would be open to a bit of special-casing for OSX:
For example, would it be possible (if not advisable) to detect:
Is PKG_CHECK_MODULES missing?
If so:
is it OSX?
Is [ -d /opt/local/share/aclocal ] true?
Does the macro exist there?
While aclocal has a few ways of appending to its search path (see https://www.gnu.org/software/automake/manual/html_node/Macro-Search-Path.html), you cannot modify that macro search path using code in configure.ac:
When the shell code in configure is run, it is too late, as the available macros have already been expanded. When autoconf (is it autoconf or something else? anyway, m4 called from autoreconf) generates configure from configure.ac by having m4 expand the macros it is also too late: aclocal has already collected the m4 macros it could find.
So what you would need is a step before the autoreconf run - which is beyond what I would consider a buildsystem needs to do.
What you can do: Put static strings into the top level Makefile.am file like e.g.
ACLOCAL_AMFLAGS = -I auto-m4 -I project-m4 -I /opt/local/share/aclocal
(this example uses auto-m4/ with AC_CONFIG_MACRO_DIR([auto-m4]) for the *.m4 files automatically put there by autoreconf/autopoint/libtoolize and project-m4/ for the project specific *.m4 files).
Of course, you should already have
m4_pattern_forbid([PKG_CHECK_MODULES])dnl
before invoking PKG_CHECK_MODULES for the first time so that the problem of the missing *.m4 file will be detected at the earliest possible time, i.e. when autoconf is about to generate a configure file with PKG_CHECK_MODULES unexpanded.
You could use some m4 code to print a lengthy error message if PKG_CHECK_MODULES is not defined. Something along the lines of (untested)
m4_ifndef([PKG_CHECK_MODULES], [dnl
m4_fatal([Could not find the PKG_CHECK_MODULES macro. Check that the pkg.m4 file is available and aclocal finds it (e.g. set ACLOCAL_PATH=/opt/local/share/aclocal).
])dnl
PKG_CHECK_MODULES([FOO], [foo])
Personally, I would go with m4_pattern_forbid and make sure OSX builds with homebrew work OOTB, and then document idiosyncrasies for building on rare and buggy systems like OSX with macports or SunOS without GNU tools in the INSTALL file.
Isn't it a bug in macports/OSX that aclocal there cannot find its *.m4 files? Shouldn't there be a dirlist file pointing to /opt/local/share/aclocal? Or perhaps they macports users should have an aclocal in their PATH which actually finds the macports macro files?
In any case, I would not consider it my build systems's job to fix a buggy system. You need to draw the line somewhere.
I have some older utilities that are only sometimes needed and it came time to use a particular one and I found it didn't work. I know that some of the other utilities in the same package were working, but rather than worry about why this one was unique, I figured it just needed a recompile on the most recent Fedora and so I ran make.
I then learned that it couldn't find cc1. So the first thing I did was: dnf update gcc
This upgraded some 11 packages but didn't cure the cc1 problem, so I did which gcc to find where that is, then made a soft link to the cc1 program in the same directory. The compile then proceeded until a / the final linking, which should be:
gcc -o run${BINTYPE} run.o hashc.o
'run' here is the utility name. But the compile returns:
gcc: fatal error: ‘-fuse-linker-plugin’, but liblto_plugin.so not found
compilation terminated.
I then did a web search and found a few stack-overflow entries, such as this one, (and a handful of non-stack-overflow pages, too) but none matched or provided a working solution.
I then found where liblto_plugin.so actually is:
/usr/lib64/bfd-plugins/liblto_plugin.so
...and checked LD_LIBRARY_PATH - the location wasn't in there, so I added it as the first entry (/usr/lib64/bfd-plugins/). That didn't work - same error.
And, I also tried going to where this distribution of Fedora seems to want to find it - which is /usr/libexec/gcc/x86_64-redhat-linux/ - and then making a soft link there, too, but that didn't work either.
OK, this should be simple, but I'm stumped!
It might be worth noting that from what I understand, this plugin is about optimizing dynamic linking at runtime, and that's simply not involved for this utility. All this program does is validate an environment before running to ensure it doesn't even try to launch unless certain conditions are met, so static linking should work fine. So maybe a workaround is to simply provide a flag that says skip the plug-ins? I'd rather "fix it correctly," but I'll settle for it doing what I need to do right now.
UPDATE
As suggested by Knud Larsen in comments, I did a re-installation of gcc and nothing changed. And, it appears the ‘-fuse-linker-plugin’ isn't even rquired these days, Great! But, there's no flag calling for its use, so it seems to be automatic; how do I turn this thing off?!
I also meet this question when install something with cargo.
note: cc: fatal error: '-fuse-linker-plugin', but liblto_plugin.so not found
compilation terminated.
Finally, I found the reason. I created the hard link cc of gcc by mistake. It should have been a soft link. It will be fine after changing it.
The instruction on the automake man page and the online manual at gnu.org don't work for me.
They say that a bare "automake" reads configure.am and writes configure. However, when I try it there's no error, but nothing is written to configure. I have to use
automake configure.am >configure
Is this a doc bug, or am I doing something wrong?
The title of the page you linked says: Using autoconf to Create configure and you are using automake...
Firstly, the file is called configure.ac, not configure.am.
Secondly, just run autoreconf to generate configure. Depending on the files present, it will call automake, autoconf, aclocal, etc. pp. in the correct sequence.
I'm trying to build a package from source. The ./configure and make steps work out, but sudo make install or sudo checkinstall results in an error:
As we can see drbd is listed twice in the /usr/bin/install -c line.
The problem is I don't really know how to go about this. As expected, this list of files (ha resource agents) is not present in any of the Makefiles or install-sh, but generated somehow on the go.
Any ideas of where to look for or how to remove duplicate entry from this list? Thank you.
Actually I was mistaken and the above list was present in one of Makefile.am files. Here is the post that helped me out:
This issue is caused because for those earlier versions we incorrectly
had those specified files listed twice in the Makefile.am and with the
newer Automake versions this causes the errors you received.
p.s. Sorry, it was a haste to ask the question. Let this thread be for reference in that case.
Has anyone seen something like this:
when running make in a project using autotools, it always rebuils everyhing. Running with make -d, shows that make looks for foo.lo files and because they are not found, always recompiles foo.c.
It seems to be related to builddir != srcdir.
The .lo files are of course in the builddir. But apparently make or libtool are expecting them somewhere else:
Debug output lookgs like this:
Prerequisite /path/to/srcdir/foo.h' is older than targetfoo.lo'.
/path/to/builddir/.deps/foo.Plo:1 Must remake target `foo.lo'.
Update It seems the problem is caused by AC_PROG_LIBTOOL. According to the documentation it expects a variable called top_builddir to be set to the builddirectory. What is the standard way to set it? Is there a autoconf macro for this?
A libtool update solved this problem