While compiling some libraries (spatialite 3.0.1, geos 3.3.3 and others) I've noticed that running ./configure results in a makefile that contains lines like this
CFLAGS = -g -O2
CXXFLAGS = -g -O2
That means that debug symbol generation is enabled by default. What I want is to disable debug compiling mode without manual makefile editing. I've ran ./configure --help for both of libraries mentioned above, but I have not found any option to get desired result. I feel that the solution should be very simple, but I'm stuck on this since I'm not very familiar with building software from sources.
OS: Linux Red Hat Enterprise 6
Assuming you're talking about autoconf/automake:
Why not just keep the debugging symbols and let anybody who doesn't like them make install-strip?
You can pass CFLAGS and CXXFLAGS along with configure script
./configure CFLAGS="-O2" CXXFLAGS="-O2"
Related
I use meson 0.53.2 on ubuntu 20.04.
I would like to have a maximally optimized executable (-Ofast) but contain all debug symbols (-g3)
If I use --buildtype=release it optimizes -O2 and the executable contains no debug symbol.
If I use --buildtype=debug it does not optimize at all and uses -g.
If I use --buildtype=debugoptimized it optimizes -O2 and uses -g.
I tried to use --debug which seems not to work, because the executable does not contain any debug symbol. Instead if I use -Ddebug=true the debug symbols are there but with the flag -g.
So how do I get gcc to compile with -Ofast -g3 flags in the least dirty way possible?
From the commandline, you can switch higher level of optimization with option optimization=3. It gives you -O3 instead -O2.
By editing meson script, you can set any flags.
if get_option('buildtype') == 'custom'
add_project_arguments('-Ofast', '-g3', language : 'cpp')
endif
And in case you cannot modify meson script, you may alter environment variables
CXXFLAGS="-Ofast -g3" meson --buildtype=custom build_c
And --reconfigure seems to not see environment variables.
A directory teeming with demonstration files called ncurses-examples-20200725 is available here:
[ftp://ftp.invisible-island.net/ncurses-examples/current/ncurses-examples.tar.gz][1]
I wanted to study the workings of the form_driver_w example so I built the programs in accordance with the README file.
If I run ./form_driver_w, the result is a command line statement: "This program requires the wide-ncurses and forms library".
That outcome occurs because the following statement is not true:
#if USE_WIDEC_SUPPORT && USE_LIBFORM && (defined(NCURSES_VERSION_PATCH) && NCURSES_VERSION_PATCH >= 20131207)
Trying to trace how and where in the labyrinth of header files and compiler switches USE_WIDEC_SUPPORT is set to true is diabolically difficult. Furthermore, since the source code uses form_driver_w, I would have expected the compiler to link to ncursesw. However the compiler call is like this:
gcc -g -O2 -o form_driver_w ../ncurses-examples-20200725/form_driver_w.o ../ncurses-examples-20200725/popup_msg.o -L/lib64 -I. -I. -I../test -DHAVE_CONFIG_H -DDATA_DIR=\"/usr/local/share\" -D_DEFAULT_SOURCE -D_XOPEN_SOURCE=600 -D_XPG5 -g -O2 -DNCURSES_STATIC -lform -lmenu -lpanel -lncurses -lutil -lm
My Debian Bullseye installation includes a binary called form_driver_w in the /usr/lib/ncurses/examples/ directory. That binary runs correctly. I do not know how it was compiled.
Compiling and running form_driver_w must be a trivial task. Does anybody know how to do it?
You'd have to configure using ncursesw:
configure --with-screen=ncursesw
(and, of course, have the development library available).
The place to find this information is by running
configure --help
which lists a few options:
General Options:
--disable-stripping do not strip (debug info) installed executables
--enable-string-hacks work around bogus compiler/loader warnings
--with-pkg-config{=path} enable/disable use of pkg-config
--disable-echo do not display "compiling" commands
Curses Version-dependent Options:
--with-ncurses-wrap-prefix naming-prefix for ncurses wrapped-variables
--disable-widec disable checks for wide-character functions
--with-curses-dir=DIR directory in which (n)curses is installed
--with-screen=XXX use specified curses-libraries
--with-ncursesw use wide ncurses-libraries
--with-ncurses use ncurses-libraries
--with-pdcurses compile/link with pdcurses X11 library
--with-curses-colr compile/link with HPUX 10.x color-curses
--with-curses-5lib compile/link with SunOS 5lib curses
--with-Xaw3d link with Xaw 3d library
--with-Xaw3dxft link with Xaw 3d xft library
--with-neXtaw link with neXT Athena library
--with-XawPlus link with Athena-Plus library
--with-x use the X Window System
--with-x11-rgb=FILE file containing X11 rgb information (EPREFIX/lib/X11/rgb.txt)
--with-form-libname=XXX override form basename of library
--with-menu-libname=XXX override menu basename of library
--with-panel-libname=XXX override panel basename of library
--disable-panel disable checks for panel functions
--disable-menu disable checks for menu functions
--disable-form disable checks for form functions
Testing/development Options:
--enable-warnings test: turn on gcc compiler warnings
--with-dmalloc test: use Gray Watson's dmalloc library
--with-dbmalloc test: use Conor Cahill's dbmalloc library
--with-valgrind test: use valgrind
--disable-leaks test: free permanent memory, analyze leaks
--disable-rpath-hack don't add rpath options for additional libraries
I'm trying to cross-compile libSDL version 1.2 for a custom made, debian based Linux system. The toolchain I'm using is already configured properly so that I just run gcc/g++ on my the desired code and the resulting output is compatible with the target machine.
When I run ./configure --help in the libSDL source directory, I see that I can basically just set some environment variables to point to my cross-compiler.
However, I also see the following options:
System types:
--build=BUILD configure for building on BUILD [guessed]
--host=HOST cross-compile to build programs to run on HOST [BUILD]
I looked into the configure.in, build-scripts/config.sub, and build-scripts/config.guess files but couldn't really figure out how it works.
Are these options required? If not, is it a good idea to use them?
With autotools, --build is what you are building on and --host is what you want it to run on (there's also --target, but that's only important if what you're compiling is itself a compiler). Autotools will generally figure out --build on their own, so don't specify it if you don't have to (but look in /usr/lib/gcc to see what your compiler probably thinks --build should be)
So, eg, if you're building for i686 on x86_64, do
./configure --host=i686-linux-gnu
(And use the -m32 options in CFLAGS, etc., but it sounds like you already have that ready.)
Whereas if you're building for x86_64 on i686, do
./configure --host=x86_64-linux-gnu
(You can build for all kinds of crazy hosts: rs6000-ibm-aix, sparc-sun-solaris, mips-idt-ecoff, etc..., assuming you have the appropriate gcc cross-compilers installed...)
GNU's page on it is here:
http://www.gnu.org/software/automake/manual/html_node/Cross_002dCompilation.html
I want to know how i can cross compile a library for ARM architecture. Suppose i have libcurl library for Intel architecture and now i want to run the application in ARM architecture using this library. What are the steps i need to perform for this cross compilation. I am using Ubuntu 32-bit machine.
I have gone through the basic steps like
./configure --host= ...
make
make install
but could not get the complete idea. Please provide some useful link or if anybody can explain the things. Any help would be greatly appreciated.
I know there is a post in SO for this already "http://stackoverflow.com/questions/5832734/cross-compiling-a-library-from-intel-to-arm" , but i did not get the things clarified by this.
Platform : linux , gcc compiler
You need to give toolchain for your architecture the host parameter, for example for arm-1808 which basically has an arm architecture, the host parameter would be arm-none-linux. I used the following configure command for my architecture, and it compiled successfully, and I am able to run the application on my arm board.
0.
If tool chain is not in your PATH, then you can include it with a command like this:
export PATH=/home/user/CodeSourcery/Sourcery_G++_Lite/bin/:$PATH
1.
./configure --host=arm-none-linux-gnueabi --build=i686-linux CFLAGS='-Os' --with-ssl=/usr/bin/openssl --enable-smtp
2.
make
3.
sudo make install
4. Now its time to build your application.
arm-none-linux-gnueabi-gcc -o email smtp-multi.c -I/usr/local/include -L/usr/local/lib -lcurl
Basically you need to give CPP and CF flags while compiling your application, to find out the CF and CPP flags you can use the following commands respectively:
curl-config --cflags
curl-config --libs
If above commands do not work then try:
arm-none-linux-gnueabi-gcc -o email smtp-multi.c -lcurl
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