In my Ubuntu machine, I have a makefile, and I want to compile the project to a different compiler then the default gcc compiler.
I read a lot about it, and I tried different methods, including:
Adding CC=<other_compiler> in the command line: make CC=<other_compiler>
Adding CC and CXX as an environment variable in the command line from which I execute make.
Adding CC=<other_compiler> inside makefile
But all of them didn't change the fact that the default compiler (gcc) was called, instead of mine compiler.
Any ideas what could have I been missing, and where else can I check?
Related
I'm using gcc+cmake in a Linux 64bits and my compilation target is Linux 32bits.
So I added -m32 to my CMAKE_C_FLAGS.
But then cmake fails with the message: The C compiler "/usr/bin/gcc" is not able to compile a simple test program.
Of course, this is because a 32bits executable can't run on 64bits arch.
I had a look on the cross compilation cmake's page, but it seems very complex for my need.
So, my question : is there a way to simply build a 32bits binary (exe or lib) using cmake?
For information, here is what I tried by using an environment variable:
Add `${myflag}` to CMAKE_C_FLAGS
Set myflag to empty.
Call cmake to generate a makefile (so it will successfully check the compiler)
Set myflag to -m32.
Call make (so it will compile with my -m32 option
But it seems that gcc doesn't evaluate user environment variables.
I am trying to cabal install a component of wxHaskell (Haskell platform 2013.2 against wxWidgets 3.0).
I was able to compile the git version with 32 bit mingw from mingw.org. But in the end, the installed wx cannot function correct, and running a minimal example gives runtime exceptions in wxc.dll. So I try to compile the same thing under TDM-GCC 4.8.1 64bit, since the wxWidgets people provide their binary in the form of TDM-GCC compiled binaries.
But I immediately run into compilation errors with TDM-GCC, telling me
error: 'strnlen' was not declared in this scope
What surprises me is that even though both mingw32 and TDM-gcc uses the same external gcc from Haskell Platform c:\HaskellPlatform\2013.2.0.0\mingw\bin\gcc.exe, one would give an error while the other compiles fine.
The first file causing problem is src\cpp\eljaccelerator.cpp. It compiles OK under mingw32:
...
c:\HaskellPlatform\2013.2.0.0\mingw\bin\gcc.exe -Wl,--hash-size=31 -Wl,--reduce-
memory-overheads -Isrc/include -IC:/MinGW/msys/1.0/local/include/wx-3.0 -IC:/Min
GW/msys/1.0/local/lib/wx/include/msw-unicode-3.0 -D__WXMSW__ -DWXUSINGDLL -D_LAR
GEFILE_SOURCE=unknown -DwxcREFUSE_MEDIACTRL -DBUILD_DLL -c src\cpp\eljaccelerato
r.cpp -o dist\build\src/cpp/eljaccelerator.o
but gives an error under TDM-gcc:
Building wxc
c:\HaskellPlatform\2013.2.0.0\mingw\bin\gcc.exe -Wl,--hash-size=31 -Wl,--reduce-
memory-overheads -Isrc/include -IC:/mingw/msys/1.0/local/include/wx-3.0 -IC:/min
gw/msys/1.0/local/lib/wx/include/msw-unicode-3.0 -D__WXMSW__ -DWXUSINGDLL -D_FIL
E_OFFSET_BITS=64 -DwxcREFUSE_MEDIACTRL -DBUILD_DLL -c src\cpp\eljaccelerator.cpp
-o dist\build\src/cpp/eljaccelerator.o
In file included from C:/mingw/msys/1.0/local/include/wx-3.0/wx/crt.h:19:0,
from C:/mingw/msys/1.0/local/include/wx-3.0/wx/string.h:4305,
from C:/mingw/msys/1.0/local/include/wx-3.0/wx/memory.h:15,
from C:/mingw/msys/1.0/local/include/wx-3.0/wx/object.h:19,
from C:/mingw/msys/1.0/local/include/wx-3.0/wx/wx.h:15,
from src/include/wrapper.h:20,
from src\cpp\eljaccelerator.cpp:1:
C:/mingw/msys/1.0/local/include/wx-3.0/wx/wxcrt.h: In function 'size_t wxStrnlen
(const char*, size_t)':
C:/mingw/msys/1.0/local/include/wx-3.0/wx/wxcrt.h:173:92: error: 'strnlen' was n
ot declared in this scope
C:/mingw/msys/1.0/local/include/wx-3.0/wx/wxcrt.h: In function 'size_t wxStrnlen
(const wchar_t*, size_t)':
C:/mingw/msys/1.0/local/include/wx-3.0/wx/wxcrt.h:187:95: error: 'wcsnlen' was n
ot declared in this scope
Failed to install wxc-0.90.1.1
I was wondering if anyone has any similar experience. Any idea what went wrong and how to fix compilation for TDM-GCC? I tried adding #include <cstring> to wxcrt.h but it doesn't change anything.
FYI, I have compiled wxWidgets 3.0.0 from source in mingw and tdm-gcc versions respectively, using
./configure --enable-stl && make && make install
I can provide more details if needed.
First of all, wxWidgets certainly does work with MinGW, the fact that only TDM binaries are provided simply means that someone volunteered to provide the latter but not the former. But all three popular versions of MinGW (the two already mentioned and MinGW-w64) do work, so there must be something wrong with the build...
However while they all work, they are certainly different compilers, so what do you mean that they both use the same gcc binary? It must be either a MinGW one or a TDM one, but it can't be both at once.
It's also very suspicious that the configure detects different flags to use for the large file support. Look at config.log, something must have gone wrong and there must be some errors in the initial stage in it.
Tutorials for gdb suggest compiling with 'gcc -g' to compile the program with debug symbols.
However, I want to debug a program compiled with make. How can I instruct make to compile with debugging symbols?
Thanks.
In order to change your compile options you need to edit the file 'Makefile' in the directory from which you run 'make'. Inside that file look for one of the following things:
The variable which defines you compiler, probably something like:
CC='gcc'
The actual line where your compiler gets called (more likely in hand-made Makefiles).
Variables called CFLAGS or CXXFLAGS
In the first two cases, just add '-ggdb' after 'gcc', in the third case it's even easier just add '-ggdb' like:
CFLAGS='-ggdb'
The makefiles I have to deal with (created by others) frequently don't make it easy to change the options to the compiler. Simply setting CFLAGS on the command line is easy but clobbers many other important compilation options. However, you can often deal with the issues by overriding the compiler macro on the make command line:
make CC="gcc -g" ...other arguments...
You need to ensure everything you're interested in debugging is compiled with the debug flag. You might use make cleanup or make clean to clear the debris, or you might resort to simpler measures (rm *.o *.a *.so or its equivalent). Or, if you have GNU Make, then use -B or --always-make to force it to rebuild everything.
If you have multi-directory builds, you need to do this in all the relevant directories.
My gcc compiler is at a custom location /my/path/hpgcc
I've downloaded the boost sources. Executed bootstrap.sh, but it fails because it runs with the default gcc.
Looking into it, I see that it fails at the first thing it does: building the Boost.Build engine:
gcc -o bootstrap/jam0 command.c compile.c debug.c expand.c glob.c hash.c hdrmacro.c headers.c jam.c jambase.c jamgram.c lists.c make.c make1.c newstr.c option.c output.c parse.c pathunix.c pathvms.c regexp.c rules.c scan.c search.c subst.c timestamp.c variable.c modules.c strings.c filesys.c builtins.c pwd.c class.c native.c md5.c w32_getreg.c modules/set.c modules/path.c modules/regex.c modules/property-set.c modules/sequence.c modules/order.c execunix.c fileunix.c
(fails because executed with the default gcc, and not my gcc version).
I've tried to change the gcc path in the user-config.jam file, but it doesn't help. Probably because the Boost.Build's build script boost_1_47_0/tools/build/v2/engine/build.sh doesn't use user-config.jam, and just uses the default locations.
Any solution?
Add the line:
using gcc : : /my/path/hpgcc ;
to user-config.jam. user-config.jam will usually be in /path/to/boost/tools/build/v2/, but you can put a custom user-config.jam or site-config.jam in any of the places listed here.
/my/path/hpgcc should be the full path to the g++ executable.
EDIT (Igor Oks) : What eventually solved the problem is that I edited boost_1_47_0/tools/build/v2/engine/build.sh to make it use my custom gcc.
We do this in our build environment by simply defining the PATH and LD_LIBRARY_PATH environment variables to pickup our desired GCC first.
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