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.
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 am trying to make a shared library for a particular problem I was working on. It has "point_sense.c" as the main file which uses functions defined in "createPolygon.c." The functions are declared in a header file "createPolygon.h."
To compile them, I used a makefile which looks like the following
all:point_sense
createPolygon.o:createPolygon.c
g++ -c -fpic createPolygon.c
libcreatePolygon.so:createPolygon.o
g++ -shared -o libcreatePolygon.so createPolygon.o
point_sense:point_sense.c libcreatePolygon.so
g++ -o point_sense -L~Desktop/Summer_2020_linux/tutorials/cpp_practise point_sense.c -lcreatePolygon
clean:
rm point_sense createPolygon.o libcreatePolygon.so
but when I make the file, it gives an output as
g++ -c -fpic createPolygon.c
g++ -shared -o libcreatePolygon.so createPolygon.o
g++ -o point_sense -L~Desktop/Summer_2020_linux/tutorials/cpp_practise point_sense.c -lcreatePolygon
/usr/bin/ld: cannot find -lcreatePolygon
collect2: error: ld returned 1 exit status
make: *** [makefile:10: point_sense] Error 1
Initially I thought this was some silly mistake, and to check I used
ld -L~/Desktop/Summer_2020_linux/tutorials/cpp_practise -lcreatePolygon -verbose
and after a long output I got (a few unimportant lines in the code are skipped in between)
ld: mode elf_x86_64
attempt to open ~/Desktop/Summer_2020_linux/tutorials/cpp_practise/libcreatePolygon.so failed
attempt to open ~/Desktop/Summer_2020_linux/tutorials/cpp_practise/libcreatePolygon.a failed
attempt to open /usr/local/lib/x86_64-linux-gnu/libcreatePolygon.so failed
attempt to open /usr/local/lib/x86_64-linux-gnu/libcreatePolygon.a failed
.
.
.
ld: cannot find -lcreatePolygon
But when I try to open 'libcreatePolygon.so' directly, I am able to open it.
$ nano ~/Desktop/Summer_2020_linux/tutorials/cpp_practise/libcreatePolygon.so
There are several threads which explain the process of doing this, but I don't see what it is that I am doing wrong. Any help is appreciated.
I am using Ubuntu 20.04.1 LTS and g++ (Ubuntu 9.3.0-10ubuntu2) 9.3.0 .
I tried to reproduce the problem here, and this error message goes away if you put a space between the -L flag and the tilde character.
The reason is: if there is no space between -L and ~, the tilde character cannot be expanded to the home directory.
I try to compile a very simple GtkAda application in command-line, on Windows. Here is the app code:
`WITH Gtk.Main ; USE Gtk.Main ;
WITH Gtk.Window ; USE Gtk.Window ;
PROCEDURE Test01 IS
win : Gtk_window ;
BEGIN
Init ;
Gtk_New(Win) ;
Win.show_all ;
Main ;
END Test01 ;`
Compiling with
gcc -c test01.adb -IC:\<<path_to_GtkAda\include\gtkada>>,
I obtain test.ali and test01.o as expected.
But how to link the libs please?
gcc test.o -LC:\<<path_to_GtkAda>>\lib
gives:
`Test01.o:Test01.adb:(.text+0xe): undefined reference to `gtk__main__init'
Test01.o:Test01.adb:(.text+0x21): undefined reference to `gtk__window__gtk_new'
Test01.o:Test01.adb:(.text+0x3e): undefined reference to `__gnat_rcheck_CE_Access_Check'
Test01.o:Test01.adb:(.text+0x5e): undefined reference to `gtk__main__main'
c:/mingw/bin/../lib/gcc/mingw32/4.8.1/../../../../mingw32/bin/ld.exe: Test01.o: bad reloc address 0x20 in section `.eh_f
rame'
c:/mingw/bin/../lib/gcc/mingw32/4.8.1/../../../../mingw32/bin/ld.exe: final link failed: Invalid operation
collect2.exe: error: ld returned 1 exit status`
PATH already contains <<path_to_GtkAda>>/bin
Thank you.
The solution usually is to use GNAT's project files as described in the documentation installed with the compiler, typically in the “doc” or "doc/gprbuild” subdirectory.
A simple example project file named “SO.gpr” might look like this:
with "gtkada";
project SO is
for Source_Dirs use (".");
end SO;
Note the part that says with "gtkada";. It means that the toolchain then will inject all switches that are necessary to make an Ada/GTK program.
Then, if you invoke the GNAT toolchain like this:
$ gnatmake -PSO test01.adb
the Ada make program will call, in sequence, gcc, gnatbind, and gnatlink. For each, the necessary arguments to the commands will be supplied automatically.
(Depending on which edition of GNAT you are using, you may also use gprbuild.)
So, for example on a Debian/GNU system with libgtkada2.24.4-dev installed, I see this:
$ gnatmake -Pso test01.adb
gcc-4.9 -c -I- -gnatA /home/bauhaus/News/SO/test01.adb
gnatbind -shared -x /home/bauhaus/News/SO/test01.ali
gnatlink /home/bauhaus/News/SO/test01.ali -shared-libgcc -L/usr/lib/x86_64-linux-gnu/ -lgtkada -lgdk-x11-2.0 -lgmodule-2.0 -lgtk-x11-2.0 -lgdk-x11-2.0 -lpangocairo-1.0 -latk-1.0 -lcairo -lgdk_pixbuf-2.0 -lgio-2.0 -lpangoft2-1.0 -lfontconfig -lfreetype -lpango-1.0 -lgobject-2.0 -lglib-2.0 -lX11 -lm -o /home/bauhaus/News/SO/test01
$
I'm trying to figure out how to set some environment variable which would make g++ to link to correct versions of the libraries.
I have some old boost libraries in /usr/lib64 (linking against these will fail) and new libraries in /v/users/regel/lib. So the linker should link against the new libraries.
Command:
$ g++ test.cpp -lboost_system -L/v/users/regel/lib
links the program correctly. However, I wish to set this as the number 1 search directory for the linker so that I don't have to specify '-L' every time I link.
The following environment variables do not seem to do the trick:
$ LIBRARY_PATH=/v/users/regel/lib g++ test.cpp -lboost_system
/tmp/regel/cc4SmBtI.o: In function `main':
test.cpp:(.text+0x5): undefined reference to `boost::system::system_category()'
collect2: error: ld returned 1 exit status
and
$ LD_LIBRARY_PATH=/v/users/regel/lib:$LD_LIBRARY_PATH g++ test.cpp -lboost_system
/tmp/regel/ccUreBZy.o: In function `main':
test.cpp:(.text+0x5): undefined reference to `boost::system::system_category()'
collect2: error: ld returned 1 exit status
Despite reading numerous articles and posts on similar subjects, I have not found a solution yet.
As the GCC manual says, LIBRARY_PATH is the correct environment variable to add directories to the library search path.
If you add -v to the g++ command you should see the LIBRARY_PATH that it uses, and you should see it includes the directory you have specified, and that it gets added to the collect2 command as -L, but you will see it gets added after the standard directories such as -L/usr/lib etc.
I don't know any way to make the directories in LIBRARY_PATH come first, I think you have to use -L for that.
Try specifying the library path in a .conf file in /etc/ld.so.conf.d/
The linker looks at paths specified in files in /etc/ld.so.conf.d/ while linking.
Make sure you run 'ldconfig' once you create the file, that will force it to update its cache.
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