autoconf (automake) won't accept
packagename_LDADD = wx-config --libs
and wants you to use packagename_LDFLAGS instead.
The problem is LDFLAGS is put in the wrong place on the command line for this parameter to work. Can LDADD be forced to take it?
Automake doesn't know that wx-config --libs is a shell expression you wish to expand.
Usually what you want to do here is hoist detection and invocation of wx-config to an autoconf m4 macro (or use one provided by wx widgets) and use the result as an explicit variable reference in automake. At that point automake will realize it is a list of libraries to add & simmer down.
Related
I want to check whether gmodule exists in my custom PKG_CONFIG_PATH
// configure.ac
AC_SUBST([PKG_CONFIG_PATH],"./glib/lib/x86_64-linux-gnu/pkgconfig/")
PKG_PROG_PKG_CONFIG
PKG_CHECK_EXISTS([gmodule-2.0],[],[
AC_MSG_ERROR(can't find gmodule in glib-2.0)
])
But I have the following error:
checking for libunwind.h... yes
checking for pkg-config... /usr/bin/pkg-config
checking pkg-config is at least version 0.9.0... yes
configure: error: can't find gmodule in glib-2.0
I'm 100 percent sure that gmodule-2.0.pc is in my custom path:
> ls ./glib/lib/x86_64-linux-gnu/pkgconfig/
gio-2.0.pc gio-unix-2.0.pc glib-2.0.pc gmodule-2.0.pc gmodule-export-2.0.pc gmodule-no-export-2.0.pc gobject-2.0.pc gthread-2.0.pc
And I can also use pkg-config to find gmodule-2.0:
> PKG_CONFIG_PATH="./glib/lib/x86_64-linux-gnu/pkgconfig/" pkg-config gmodule-2.0 --cflags
-pthread -I/home/xxx/fuzz/test/StochFuzz/glib/include -I/home/xxx/fuzz/test/StochFuzz/glib/include/glib-2.0 -I/home/xxx/fuzz/test/StochFuzz/glib/lib/x86_64-linux-gnu/glib-2.0/include
Do I miss something?
Do I miss something?
It looks like you are expecting this ...
AC_SUBST([PKG_CONFIG_PATH],"./glib/lib/x86_64-linux-gnu/pkgconfig/")
... to cause configure to use ./glib/lib/x86_64-linux-gnu/pkgconfig/ as the PKG_CONFIG_PATH when it runs pkg-config. In that case, you are at least missing that
the purpose of AC_SUBST() is to create an output variable. You want an output variable if you want to convey the pkg-config path to your Makefiles, but that is not directly relevant to your configure script.
although AC_SUBST does set the value of the specified shell variable if you designate a value for it,
It does not necessarily export that variable.
The assignment does not necessarily appear in the configure script at a place corresponding to the macro's location in configure.ac.
if you are trying to use components that are bundled with your project (and surely that's what you are doing if the wanted details are provided by pkg-config data from within your own source tree) then pkg-config is way overkill. Just put the needed paths and flags in your Makefile.am file(s), or if you're not using Automake then directly in your Makefile.in file(s).
If you insist on doing it with pkg-config anyway, then this variation will likely induce the behavior you want from the PKG_CHECK_EXISTS macro:
# configure.ac
PKG_CONFIG_PATH=./glib/lib/x86_64-linux-gnu/pkgconfig/
export PKG_CONFIG_PATH
PKG_PROG_PKG_CONFIG
PKG_CHECK_EXISTS([gmodule-2.0],[],[
AC_MSG_ERROR(can't find gmodule in glib-2.0)
])
If you also need to convey your custom PKG_CONFIG_PATH to your makefiles then you can add ...
AC_SUBST([PKG_CONFIG_PATH])
... but you shouldn't. Notwithstanding the fact that you shouldn't be using pkg-config at all in this case (see above), when you do use pkg-config in an Autotools build system, the best way to use it is entirely within configure. Extract the needed paths and flags there, and convey those to your makefiles via output variables.
I tried to compile my context.c file with "gcc $(pkg-config --cflags --libs glib-2.0)" context.c.
But it doesn't work because it does not find galloca header file:
context.c:3:10: fatal error: galloca.h: file or directory not found #include <galloca.h>
I tried "gcc $(pkg-config --cflags --libs glib-2.0 glib)" where galloca.h is located /usr/include/glib-2.0/glib. But after adding glib to the compile command, it does not even find glib.h anymore, which is in /usr/include/glib-2.0.
I tried to add the all necessary paths to PKG_CONFIG_PATH with "export PKG_CONFIG_PATH=/usr/include/glib-2.0/gio/pkgconfig" and so on.... without success.
I also added all necessary library paths to /etc/ld.so.conf and sudo ldconfig -v, also without success.
It is not the first time i face the problem, that necessary libraries can't be found on this system while compiling, but as we in germany say: "i am at the end of my latin", so i have no more clue how to solve this issue and would be gratfull for any help.
Thanks in advance.
PS: I use a raspberry pi 4B 8GB and raspbian linux.
Your library path will not help it to find include file.
Maybe you want -I/usr/include/glib-2.0 -I/usr/include/glib-2.0/glib
Maybe your build script accept CFLAGS environment variable where you can put this option.
Or maybe you change (edit) source code,
#include <galloca.h>
become
#include <glib/galloca.h>
because already it looks correctly in /usr/include/glib-2.0, only the subdirectory is wrong
Afterwards you discover if you must set some path also for libraries. But one thing by one, first compile, then worry about the link. You talk about ld.so.conf. Really this is for runtime, but OK, at build it is last option after trying everything else (see at man ld and search ld.so.conf). Really for build time library path you want -L option maybe with LDFLAGS environment variable. But as I say, first try compile and then discover if link problem.
Wer mit seinem Latein am Ende ist, muss Griechisch sprechen.
I've been trying to generate Makefile rules that execute before the
automake Makefile rules. I've seen I can define "all-local" and "hooks" rules, but these are executed after the "all" and other
rules, for instance.
Is there any way that I could execute a code of mine before the
automake added rules? I want to automatically generate files in a
directory, but the compilation process through make always tries to
compile programs following automake Makefile rules. If I could add a
"pre-" rule, I could generate the needed files, then let the normal
compilation process to run.
I know about BUILT_SOURCES, but I'm trying not to use it
Is that possible?
Thanks!
There isn't a way to do this.
In general in a Makefile, if you want to do this, you should instead consider adding proper dependencies where needed.
Makefiles can have the same target with different prerequisites, in which case the prerequisites will be merged:
# The following will be equivalent to 'target: prerequisite1 prerequisite2'
target: prerequisite1
target: prerequisite2
This can be inferred from the GNU make manual (really bad explanation there, but I did not find anything better).
You can leverage this feature in your own Makefile.am:
all: all-prehook
all-prehook:
echo Prehook called here
.PHONY: all-prehook
Be careful automake will complain (Warning: overrides Automake target or something similar). You could shut it up by using -Wno-override: if your are using autoconf, just add it to your AM_INIT_AUTOMAKE call.
I have a working SDL/Haskell application that I would like to build using Cabal instead of the current Makefile (because that is the "Haskell way"). The Makefile is itself very simple, and I was hoping that the default cabal build process could allow me to reconstruct a build command specified in my Makefile. The problem is that it makes use of "sdl-config", a utility that gives you all the necessary cc- compiler options:
wrapper.o: SDLWrapper_stub.h
ghc -no-hs-main `sdl-config --cflags` -Wall wrapper.c -c
Cabal does not seem to expand that into a shell call when calling GHC. How can I specify that sdl-config's options should be fed into GHC when compiling wrapper.o?
Using the configure style in Cabal, you can write a little configure script that substitutes a variable for the output of the sdl-config command. The values will then be replaced in a $foo.buildinfo.in file, yielding a $foo.buildinfo file, that Cabal will include in the build process.
General solution: the configure script
#!/bin/sh
SDLFLAGS=`sdl-config --cflags`
echo Found "$SDLFLAGS"
sed 's,#SDLFLAGS#,'"$SDLFLAGS"',' z.buildinfo.in > z.buildinfo
The $foo.builinfo.in file
cc-options: #SDLFLAGS#
The .cabal file
Build-type: Configure
When you run "cabal configure" the "cc-options" field in z.buildinfo will be created to hold:
cc-options: -I/usr/include/SDL -D_GNU_SOURCE=1 -D_REENTRANT
which cabal will include in the build.
Done.
Specific solution for pkg-config tools
For tools that support the pkg-config-style of configuration, such as sdl or cairo and others, Cabal has specific support already:
pkgconfig-depends: package list
A list of pkg-config packages, needed to build this package. They can be annotated with versions, e.g. gtk+-2.0 >= 2.10, cairo >= 1.0. If no version constraint is specified, any version is assumed to be acceptable. Cabal uses pkg-config to find if the packages are available on the system and to find the extra compilation and linker options needed to use the packages.
If you need to bind to a C library that supports pkg-config (use pkg-config --list-all to find out if it is supported) then it is much preferable to use this field rather than hard code options into the other fields.
So for sdl you just need:
pkgconfig-depends: sdl
Use the Configure build type in your $PROJ_NAME.cabal file and generate a $PROJ_NAME.buidinfo file from a $PROJ_NAME.buildinfo.in template with a configure script. Look at the source of the SDL library on Hackage for an example. This section of the Cabal user guide provides more details.
One tip: do not forget to mention $PROJ_NAME.buildinfo.in and configure in the extra-source-files field.
I've got a proprietary program that I'm trying to use on a 64 bit system.
When I launch the setup it works ok, but after it tries to update itself and compile some modules and it fails to load them.
I'm suspecting it's because it's using gcc and gcc tries to compile them for a 64 bit system and therefore this program cannot use these modules.
Is there any way (some environmental variables or something like that) to force gcc to do everything for a 32 bit platform. Would a 32 bit chroot work?
You need to make GCC use the -m32 flag.
You could try writing a simple shell script to your $PATH and call it gcc (make sure you don't overwrite the original gcc, and make sure the new script comes earlier in $PATH, and that it uses the full path to GCC.
I think the code you need is just something like /bin/gcc -m32 $* depending on your shell (the $* is there to include all arguments, although it might be something else – very important!)
You may get a 32-bit binary by applying Alan Pearce's method, but you may also get errors as follows:
fatal error: bits/predefs.h: No such file or directory
If this is the case and if you have apt-get, just install gcc-multilib
sudo apt-get install gcc-multilib
For any code that you compile directly using gcc/g++, you will need to add -m32 option to the compilation command line, simply edit your CFLAGS, CXXFLAGS and LDFLAGS variables in your Makefile.
For any 3rd party code you might be using you must make sure when you build it to configure it for cross compilation. Run ./configure --help and see which option are available. In most cases you can provide your CFLAGS, CXXFLAGS and LDFLAGS variables to the configure script. You also might need to add --build and --host to the configure script so you end up with something like
./configure CFLAGS=-m32 CXXFLAGS=-m32 LDFLAGS=-m32 --build=x86_64-pc-linux-gnu --host=i686-pc-linux-gnu
If compilation fails this probably means that you need to install some 32 bit development packages on your 64 bit machine