I'm having trouble building a project that attempts to check for the presence of shm_open and shm_unlink. The relevant lines of configure.ac are:
# Avoid adding rt if absent or unneeded
AC_CHECK_LIB(rt, shm_open, [EXTRA_LIBS="$EXTRA_LIBS rt" CFLAGS="$CFLAGS -lrt"])
# needs -lrt on linux
AC_CHECK_FUNCS([shm_open shm_unlink])
The AC_CHECK_LIB line succeeds, however AC_CHECK_FUNCS fails for both. Looking in config.log, I see
configure:4133: checking for shm_open in -lrt
configure:4158: /usr/bin/gcc -o conftest -fno-stack-protector -Wl,--hash-size=31 -Wl,--reduce-memory-overheads conftest.c -lrt >&5
configure:4158: $? = 0
configure:4167: result: yes
configure:4178: checking for shm_open
configure:4178: /usr/bin/gcc -o conftest -fno-stack-protector -lrt -Wl,--hash-size=31 -Wl,--reduce-memory-overheads conftest.c >&5
/tmp/ccg0yu56.o: In function `main':
conftest.c:(.text+0xa): undefined reference to `shm_open'
collect2: ld returned 1 exit status
It appears that the only difference between the two checks is the position of the -lrt argument. When I try running gcc on a simple file manually, I get the same behavior, i.e. linking succeeds only when -lrt comes after the source file input.
So, what do I need to do so configure will determine that shm_open and shm_unlink exist? I suspect this is something particular to my system, as the project I'm configuring is pretty widely used (the unix package bundled with the ghc compiler), and it used to work (when I built this package on a different system with gcc-4.4.5, it worked, however that environment is no longer available). My preferred solution would be either a change to the system/environment or some combination of flags to configure, however if there's a standard modification for configure.ac that I could send upstream, that's acceptable also.
I've tried various combinations of CFLAGS and LDFLAGS, but the -lrt flag always appears before the input file, so the check still fails.
My system is Ubuntu 12.04 (precise)
$gcc --version
gcc (Ubuntu/Linaro 4.6.3-1ubuntu5) 4.6.3
$ uname -a
Linux hostname 3.2.0-26-generic #41-Ubuntu SMP Thu Jun 14 17:49:24 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux
Thanks!
Macro have full form:
AC_CHECK_LIB (library, function, [action-if-found], [action-if-not-found], [other-libraries])
Please note other-libraries. This option is useful specifically for cases you described -- to pass -lm, -lrt and other common guys to avoid unresolved references in linker ordering.
Check doc page for more information on AC_CHECK_LIB macro
Related
amtssk#DEVICE PERT % make
/usr/local/bin/gfortran-11 -fno-backslash -Wall -Wno-tabs -O -m64 -o pert objects/main.o objects/start.o objects/metric.o objects/march.o objects/mar1d.o objects/usrpq.o objects/bound.o objects/flux.o objects/plot.o objects/rwmodel.o objects/utilities.o objects/vsr.o objects/usr.o objects/myio.o -L /Users/amtssk/OneDrive - University of Leeds/oldmac/Computing/Serial/pgplot -lpgplot -lpng -lz -L/usr/X11R6/lib -lX11
gfortran-11: error: -E or -x required when input is from standard input
make: *** [pert] Error 1
I have found the reason - the very unfortunate name for the corporate OneDrive folder, OneDrive - University of Leeds. It was quoted in the relevant path variable but became unquoted when passed to the compiler. Thank you Albert, I have just noticed you pinpointing this too!
I'm trying to compile AODV for ARM linux. I use a SabreLite as a board with kernel version 3.0.35_4.1.0. It's worth mention that i'm using openembedded to create my Linux Distribution for my board.
The AODV source code (http://sourceforge.net/projects/aodvuu/) has a README file which give some indications on how to install it on ARM as stated a bit here.
(http://w3.antd.nist.gov/wctg/aodv_kernel/kaodv_arm.html).
I was able to upgrade the makefile in order to be used with post 2.6 kernel version ( as stated above, i have the 3.0.35_4.1.0 kernel version).
So, basically, what i am trying to do is that i have to create a module (let's say file.ko) and then load it into the ARM (with insmod file.ko command).
To do that, i am using a cross compiler which some values are stated below:
echo $CC :
arm-oe-linux-gnueabi-gcc -march=armv7-a -mthumb-interwork -mfloat-abi=hard -mfpu=neon -mtune=cortex-a9 --sysroot=/usr/local/oecore-x86_64/sysroots/cortexa9hf-vfp-neon-oe-linux-gnueabi
echo $ARCH=arm
echo $CFLAGS: O2 -pipe -g -feliminate-unused-debug-types
echo $LD :
arm-oe-linux-gnueabi-ld --sysroot=/usr/local/oecore-x86_64/sysroots/cortexa9hf-vfp-neon-oe-linux-gnueabi
echo $LDFLAGS :
-Wl,-O1 -Wl,--hash-style=gnu -Wl,--as-needed -Wl,--as-needed
when i launch "make command", i get the following errors:
LD [M] /home/scof/script_emulation/AODV/aodv-uu/lnx/kaodv.o
arm-oe-linux-gnueabi-ld: unrecognized option '-Wl,-O1'
arm-oe-linux-gnueabi-ld: use the --help option for usage information
It states that there is something wrong with the linker. This linker comes from the cross compilation tools and i normally shouldn't touch it.
Anyway, to get this above errors fixed, i try to withdraw the LDFLAGS like this:
export LDFLAGS='',
and after this, the make command works and i get the module kaodv.ko. But when i insert it into my ARM to check, it does not work. It actually freeze my terminal
So my question is, do i have to specify the LDFLAGS when compiling ? Does withdrawing LDFLAGS can have impact on the generated kernel module.
Actually, i try to understand where might be the problem and the only thing that come to me is that may be i should not change manually the LDFLAGS. But if i don't change de LDFLAGS, i get the unrecognized option error.
My second question related to that is, what are the possibly value of LDFLAGS
in ARM compilation
Thanks !!
echo $LDFLAGS : -Wl,-O1 -Wl,--hash-style=gnu -Wl,--as-needed -Wl,--as-needed
There are two common methods of invoking the linker in a GCC-based toolchain. One is to do it directly, but another is to use GCC as a front end to invoke the linker, rather than invoke it directly. When doing this, options intended for the linker are prefixed with -Wl, so that GCC knows to pass them through rather than interpret them itself.
In your case the error message from LD itself
arm-oe-linux-gnueabi-ld: unrecognized option '-Wl,-O1'
Indicates that your build system is passing LDFLAGS directly to the linker, and not by way of GCC.
Therefore, you should remove the -Wl, prefix and your LDFLAGS would instead be
-O1 --hash-style=gnu --as-needed --as-needed
(the duplication of the last argument is probably pointless but benign)
-O1 is an option that tells the linker to optimize. I believe it something new, and your linker may be slightly out of date. Try removing -Wl,-O1, it should still work.
I'm trying to compile GNU Source highlight in my home directory.
I configured with a prefix and --with-boost=/path/to/boost/root/dir/ and no errors were reported.
But when I try to build I got the following error:
$ make
... # lots of output
libtool: link: g++ -shared -nostdlib /usr/lib/gcc/x86_64-redhat-linux/4.1.2/../../../../lib64/crti.o /usr/lib/gcc/x86_64-redhat-linux/4.1.2/crtbeginS.o .libs/copyright.o .libs/reportbugs.o .libs/fileutil.o .libs/substfun.o .libs/stopwatch.o .libs/utils.o .libs/ioexception.o .libs/settings.o .libs/versions.o .libs/verbosity.o .libs/sourcehighlight.o .libs/styleparser.o .libs/stylescanner.o .libs/outlangdefparser.o .libs/stylecssparser.o .libs/stylecssscanner.o .libs/outlangdefscanner.o .libs/debuglistener.o .libs/langmap.o .libs/stylefileparser.o .libs/langelem.o .libs/statelangelem.o .libs/langelems.o .libs/statestartlangelem.o .libs/stringlistlangelem.o .libs/delimitedlangelem.o .libs/langelemsprinter.o .libs/namedsubexpslangelem.o .libs/stringdef.o .libs/highlightrule.o .libs/highlighttoken.o .libs/highlightstate.o .libs/highlightrulefactory.o .libs/highlightstateprinter.o .libs/sourcehighlighter.o .libs/sourcefilehighlighter.o .libs/linenumgenerator.o .libs/lineranges.o .libs/regexranges.o .libs/formatter.o .libs/formattermanager.o .libs/textstyle.o .libs/textstyleformatter.o .libs/bufferedoutput.o .libs/preformatter.o .libs/wordtokenizer.o .libs/ctagscollector.o .libs/readtags.o .libs/ctagsformatter.o .libs/srcuntabifier.o .libs/textstyleformatterfactory.o .libs/docgenerator.o .libs/doctemplate.o .libs/chartranslator.o .libs/textstylebuilder.o .libs/fileinfo.o .libs/ctagsmanager.o .libs/regexhighlightrule.o .libs/regexrulefactory.o .libs/regexpreprocessor.o .libs/highlightstatebuilder.o .libs/highlightbuilderexception.o .libs/langdefmanager.o .libs/langdefparser.o .libs/langdefscanner.o .libs/languageinfer.o .libs/parserexception.o .libs/stringtable.o .libs/vardefinitions.o .libs/sourcehighlightutils.o .libs/yywrap.o -Wl,--whole-archive ../../gl/.libs/libgnu.a -Wl,--no-whole-archive -lboost_regex -L/usr/lib/gcc/x86_64-redhat-linux/4.1.2 -L/usr/lib/gcc/x86_64-redhat-linux/4.1.2/../../../../lib64 -L/lib/../lib64 -L/usr/lib/../lib64 -lstdc++ -lm -lc -lgcc_s /usr/lib/gcc/x86_64-redhat-linux/4.1.2/crtendS.o /usr/lib/gcc/x86_64-redhat-linux/4.1.2/../../../../lib64/crtn.o -Wl,-soname -Wl,libsource-highlight.so.1 -o .libs/libsource-highlight.so.1.1.0
/usr/bin/ld: cannot find -lboost_regex
collect2: ld returned 1 exit status
Note that, I have Boost loaded in my environment, in fact:
$ echo $LD_LIBRARY_PATH
/path/to/boost/root/dir/lib:/other/path/lib
and ls shows that /path/to/boost/root/dir/lib/libboost_regex.so exists and is a symbolic link to libboost_regex.so.1.47.0
How is this possible? How can I solve it?
At linking time, the correct environment variable to use to define the path where to find the libraries is LIBRARY_PATH, not LD_LIBRARY_PATH. The former is equivalent to specifying -L in the gcc arguments, while the latter is used at runtime, like PATH, to find the binary executables. See this for more information.
In a later stage of the gnu-make process gmake sent a command similar to:
gcc -static foo.so.0 bar.o bizz.o buzz.o -pthreads -lrt
In that command, what dos the -lrt mean?
That has not related to make; make will never add a flag like that on its own. Whomever wrote your makefile will have added that flag to the link line themselves. That is a compilation command, and -lrt is a flag passed to the compiler. The -l flag specifies that you should link with a library, and the name of the library follows; so for -lrt it means "link with the rt library". This causes the linker to go look for libraries named librt.a or librt.so (for shared libraries) and link them with the output file.
When I try to build the following program:
#include <stdio.h>
int main(void)
{
printf("hello world\n");
return 0;
}
On OS X 10.6.4, with the following flags:
gcc -static -o blah blah.c
It returns this:
ld: library not found for -lcrt0.o
collect2: ld returned 1 exit status
Has anyone else encountered this, or is it something that noone else has been affected with yet? Any fixes?
Thanks
This won’t work. From the man page for gcc:
This option will not work on Mac OS X unless all libraries (including libgcc.a) have also been compiled with -static. Since neither a static version of libSystem.dylib nor crt0.o are provided, this option is not useful to most people.
Per Nate's answer, a completely static application is apparently not possible - see also man ld:
-static Produces a mach-o file that does not use the dyld. Only used building the kernel.
The problem in linking with static libraries is that, if both a static and a dynamic version of a library are found in the same directory, the dynamic version will be taken in preference. Three ways of avoiding this are:
Do not attempt to find them via the -L and -l options; instead, specify the full paths, to the libraries you want to use, on the compiler or linker command line.
$ g++ -Wall -Werror -o hi /usr/local/lib/libboost_unit_test_framework.a hi.cpp
Create a separate directory, containing symbolic links to the static libraries, use the -L option to have this directory searched first, and use the -l option to specify the libraries you want to use.
$ g++ -Wall -Werror -L ./staticBoostLib -l boost_unit_test_framework -o hi hi.cpp
Instead of creating a link of the same name in a different directory, create a link of a different name in the same directory, and specify that name in a -l argument.
$ g++ -Wall -Werror -l boost_unit_test_framework_static -o hi hi.cpp
You may also try LLVM LLD linker - I did prebuilt version for my two major OSes - https://github.com/VerKnowSys/Sofin-llds
This one allows me to link for exmple: "Qemu" properly - which is impossible with ld preinstalled by Apple.
And last one is - to build GCC yourself with libstdc++ (don't).