I am trying to statically cross-compile an Application for ARM using the Linaro-Toolchain 7.1.1 . The final elf file is dependent on two shared-objects. I need to statically compile the application because there are dependencies that are not available on my target-system (eg. libstdc++). The -L and -I flags are in the makefile and everything works normally without the -static Flag. However when i use the -static flag, my linaro-linker tells me that it cannot find the dependencies, even though i know they are there as liba.so and libb.so. Any help or point to literature is appreciated, i feel like i did not fully understand what -static does, eventhough i did my research online.
Thanks
Thanks to your comments i was able to solve my problem and understand why i had it.
As user RPGillespie mentioned, the -static flag needs archived (libx.a) versions of the objects, so i had to compile the .o files to .a files using the ar-tool from the linaro toolchain.
Furthermore, as user RPGillespie refered me to, i had to specify the archives x using -l:libx.a instead of -lx in the g++ command.
Also it took me some time to notice that if the x.a files are not present, the linker will link dynamically. In my makefile the executable was compiled before the x.a file was available (because i just modified the makefile used to build the x.so).
Related
I'm using ortools in c++ to model a vehicle routing problem. I was wondering whether there was a way to compile the code using my own Makefile by including the proper flags for the compiler, so that I don't have to use
make build SOURCE=/path/to/my/program
I have compiled ortools from source on Debian 10, making sure to follow the proper instructions on the guide (make third-party then make cc then make install_cc). make test_cc runs and finished without problems, so I don't think there is any issues with the installation.
The only clue that I found about this topic was someone writing they used
g++ -std=c++11 -o my_program my_program.cc -I/usr/local/include/or-tools -lortools
to compile their program, but upon trying that, I have a lot of undefined references. I have read somewhere that one should use -std=c++17 instead of -std=c++11 but either way it does not work.
Please let me know if you need more details.
All binary packages comes with a supplied makefile.
You can see the source here: https://github.com/google/or-tools/blob/stable/tools/Makefile.cc.java.dotnet
If you run make detect_cc. It will print out all compiling and linking options for your platform.
Since ortools is a shared library, you will have to specify its path using the environment variable LD_LIBRARY_PATH in addition to specifying the path using the -L flag.
export LD_LIBRARY_PATH=${LD_LIBRARY_PATH}:<path-to-lib>.
You can put the export command above in the .bashrc file or run it every time your run the code. Also, you will have to used C++17.
I have compiled gcc 5.3.0 from source on an aws.ami linux to learn more about the entire development compiling chain. I have searched a number of threads for several hours and have not found the right combination to understand exactly what is going on.
Looking in the .configure --help, I set the flag --includedir=/home/mybin/include and compiled the programs with no errors, using all the flags under Fine tuning of the installation directories:
When I compile a program passing g++ -v test.cc I see that by default the compiler is looking in
#include "..." search starts here:
#include <...> search starts here:
/home/mybin/lib/gcc/x86_64-unknown-linux-gnu/5.3.0/include
/usr/local/include
/home/mybin/lib/gcc/x86_64-unknown-linux-gnu/5.3.0/include-fixed
/usr/include
End of search list.
for include programs such as map & iostream etc.
Q1: why doesn't the -v output show the --includedir in the search. I note it does however look there for #include programs.
Q2: I note that when the make install happened it did not copy the files from the compile tmp directory /home/tmp/gcc-5.3.0/libstdc++-v3/include/std/.... to the --includedir. Is there a flag I have missed to get it to dump these files into that dir?
Q3: Also using the --help output I have set CPPFLAGS="-I/home/anotherBin" to test if it will scan this dir for other include files. However it does not seem to work.
So I tried each of the following with no success, what is the correct flag to set?
LDFLAGS="-L/home/anotherBin"
linker flags, e.g. -L<lib dir> if you have libraries in a nonstandard directory <lib dir>
LIBS="-l/home/anotherBin"
libraries to pass to the linker, e.g. -l<library>
You have (understandably) misunderstood the function of the --includedir parameter of
./configure. This is a standard parameter of GNU autotools ./configure scripts,
not just GCC's. The same if true for all the other ./configure options under
the heading Fine tuning of the installation directories. They are boilerplate.
The --includedir parameter specifies a non-default directory in which to install the
header files that contain the APIs of a library or libraries that are installed
by the script. Thus e.g. if you made an autotools package for a library
libfoobar that you had written, and I decided to install the package with
./configure --includedir=/usr/local/include/foobar --libdir=/usr/local/lib/foobar
then when I compiled and linked a program using libfoobar:
main.c
#include <foobar.h>
int main(void)
{
foo();
bar();
return 0;
}
I would have to do it like:
gcc -I/usr/local/include/foobar -c -o main.o main.c
gcc -o prog main.o -L/usr/local/lib/foobar -lfoobar
GCC is not a library that you link with your programs. You don't
#include any such thing as "the GCC API" in your source code. --includedir
is not relevant.
In the case of your question Q3 you are also confused about the function of the ./configure variable,
CPPFLAGS. This variable and its fellows (CFLAGS, CXXFLAGS, LDFLAGS, etc.) affects
the behaviour of the compiler you already have when it is
building your new GCC. They have no effect on the behaviour of the new compiler that you build.
In the typical installation with C and C++ (leaving aside the other supported languages),
GCC comprises various cooperating tools for compiling, assembling and linking programs in
those languages plus implementations of the Standard libraries of
those languages. The installed locations of the tools, the binaries of the
Standard libraries and the header files of the Standard libraries are all primarily
controlled by the (specified or default) --prefix configure option, whereby a standard relationship
is maintained between all of these installed locations.
Do not depend on ./configure help to install GCC. Start at the GCC Wiki,
Installing GCC. Read that page carefully and
follow the links as you find necessary, including Installing GCC: Configuration.
I refer you especially to these words on that page:
Options specification
Use options to override several configure time options for GCC. A list of supported options follows;
‘configure --help’ may list other options, but those not listed below may not work and should not normally be used.
(My emphasis)
DMD 2.60 on Ubuntu 12.04 ...
I want to create a static binary, so that I can run it in an ages old environment.
dmd doesn't have '-static' flag.
I tried passing '-static' flag to the linker with "dmd -L-static ..." - get error message
/usr/bin/ld: cannot find -lgcc_s
Compiling C code with "gcc -static ..." works fine.
Is it something I miss ?
Thanks !
It doesn't currently work if you use dmd to link due to how it passes the linker flags to the linker. You need to build everything with -c to generate object files and then link those manually with either gcc or ld.
I should point out though that in general, statically linking glibc is considered to be a bad idea. It may very well work and be the correct solution in your case, but it definitely has potential issues (I don't remember the details though). So, you probably shouldn't do it unless you actually need to.
I have downloaded the OpenSSL binary file. I would like to create a static library for my C++ program in Ubuntu.
Meaning that they are in the same directory.
http://www.openssl.org/source/
Add -static parameter to gcc when you are linking. I expect you want to static binary without any dynamic loaded libraries. In other case, add full path to libssl.a as object file to linking in your build system. You have not specified how are you going to build your application.
Manually, you would use something like:
gcc -o application yourcode.c yourcode2.c /usr/lib/libssl.a
or better
gcc -static -o application yourcode.c yourcode2.c -lssl
Downloading binary for Linux is bad idea in most cases. If you want static binary, this should help. If you need custom build of library with special features, you need to download and build that library from sources yourself.
Anyway, similar question to yours is answered here at Static link of shared library function in gcc
You might also check Linux static linking is dead? to discover there are maybe too many problems to even consider static linking.
And if you need more information about linking under Linux, check nice tutorial at http://www.yolinux.com/TUTORIALS/LibraryArchives-StaticAndDynamic.html
Where can I find an writeup that shows me how to set up a tool chain for WxWidgets (C++) on linux/ubunto and/or OS X.
I downloaded, compiled & installed WxWidgets both on linux and OS X, compiled and tried the samples, but seem to be stuck setting up a compile environment in my own home directory.
DialogBlocks from http://www.dialogblocks.com looked promising, but it insists on recompiling WxWidgets again and again .. must be something about it I don't understand.
Writing code from scratch seems to fail due to a lack of paths to libraries, tools or whatnot .. again a lack og understanding on my part, I am sure.
So, can anyone point me to a tool chain setup, that has more than the bare minimum of instructions and fills in some of the "why" instead of only the minimal "what".
Like all C/C++ programs, the compiler has to know in what directories to look for include files, and the linker has to know what libraries it should link to.
The WxWidgets package, if installed correctly, includes the program wx-config. This can be used while compiling and linking, like so:
g++ $(wx-config --cxxflags) -c my_prog.cpp
g++ my_prog.o $(wx-config --libs) -o my_prog
I've found these two pages to be of help when setting up wxWidgets for Eclipse and MinGW.