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
Related
I am trying to compile GCC from source. After make finishes, I could not find the GCC binary executable. Here is the configure command I used:
../gcc-svn/configure --prefix=/home/user/Documents/mygcc
Here are my questions specifically:
What should I expect make install does?
Is make install going to do more compilation or just moves some files to ~/Documents/mygcc? If it is the latter where the GCC executable resides?
Any other directory in my system also get affected by make install?
Thank you in advance.
gcc-7 isn't working when I am trying to build a linux kernel.
The command which I am using:
make export CROSS_COMPILE=/usr/bin/arm-linux-gnueabi-gcc-7
Output:
make: /usr/bin/arm-linux-gnueabi-gcc-7gcc: Command not found
It has added gcc automatically after gnueabi- but not gcc-7 how do I stop it adding gcc automatically?
The CROSS_COMPILE variable contains only the prefix needed for cross-compilation, apparently.
Most likely you can reset the CC variable to choose a different named compiler. It's been a very long time since I tried to build the Linux kernel so I'm not sure, but something like this may work:
make export CROSS_COMPILE=arm-linux-gnueabi- CC=gcc-7
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.
This question may sound a little absurd. Facts:
I have a program written in C++.
It uses lot of in-house libs.
I don't have read permission to the libs.
So I have to build with a given tool which does have access to the lib headers and archives.
Stuck on gcc 4.3
I have a local build of gcc 4.5
I want g++ to use my local g++ instead of the old version.
Is there any way to get this done?
Use the full path of the compiler instead of invoking it without specifying the path.
Many configure scripts accept the CC environment variable:
export CC=/usr/bin/gcc44 for example. If you have a configure script, try ./configure --help to see if it's supported.
Assuming you have g++ in your ~/bin folder, could you add
export PATH=~/bin:$PATH
to your shell's .profile file (.bash_profile for bash). Then when you log in again and do which g++ it should show your local version of g++.
I've migrated an Oracle database and Oracle HTTP server install from a 32-bit machine to a 64-bit machine - both machines running Linux. Oracle Database is 64-bit, but the (Apache) HTTP server is 32-bit.
I use some non-Oracle DSOs (mod_ntlm for one) but whenever I run the standard "make install" type thing I end up with a 64-bit module.
Is there a standard way to compile 32-bit Apache modules on a 64-bit machine?
As an alternative to Andrew Medico's answer, use '-m32' for 32-bit compilations and '-m64' for 64-bit compilations on PPC or SPARC or Intel machines - since you don't actually mention which chip architecture you are using and that notation works on all of these.
I often use:
CC="gcc -m32" ./configure
to ensure a 32-bit compilation (or, more frequently, CC="gcc -m64" to ensure 64-bit compilation).
Question: "Is CC an environment variable used by make?"
Answer: Yes, though in this case, it is also recognized by configure, which is a shell script generated by autoconf. The notation I used - which is what I use at the command line - sets CC in the environment while the configure command is run. The other answer suggests using:
./configure CC="gcc -m32"
I assume that works and achieves much the same effect; I've not tried it so I don't know that it works.
If you run ./configure --help | less, you will see information (often just standard information) about how to use the script. And at the end, it will list (some of the) relevant environment variables, of which CC is one.
The advantage of setting the C compiler to "gcc -m32" is that the 32-bit flag is set every time the compiler is used - there is very little room for it to go wrong. If you set a flags variable (CFLAGS, etc), there is a chance that some command won't use it, and then things can go awry.
Also, going back to the question, make certainly uses a variable (macro) called CC. And you can set that on the make command line:
make CC="gcc -m32"
That overrides any setting in the makefile. By contrast, using an environment variable, the setting in the makefile overrides the value in the environment, so setting CC as an environment variable is less helpful. Although make -e gives the environment precedence over the makefile, it is usually a dangerous option to use - it can have unexpected side-effects.
./configure CFLAGS="-march=i686"
should do it
Along with the -m32 flag in gcc, you may need to include the -melf_i386 flag for ld to properly link the 32bit object files to the 32bit libraries if you have both the 32bit and 64bit libraries. The standard ld on 64bit linux boxes will default to the 64bit libraries and you get a compatibility error when the linking occurs.