I'm trying to build a c++ project on Ubuntu 12.04 64-bit.
the project is 32-bit.
At the terminal output I receive such lines:
ibcrypto.a(bio_b64.o)' is incompatible with i386 output
/usr/bin/ld: i386:x86-64 architecture of input file `/usr/lib/x86_64-linux-
gnu/libcrypto.a(bio_asn1.o)' is incompatible with i386 output
collect2: ld returned 1 exit status
make[2]: * [linux/release_32/cesmagent] Error 1
I thought it had something to do with libssl0.9.8, but so I did "sudo apt-get install libssl0.9.8:i386" but there already was the newest version of it.
Can any one please help me here?
The linker is trying to link against the 64-bit version of libcrypto.a because it can't find a 32-bit version.
You say you have this:
$ locate libcrypto.a
/usr/lib/x86_64-linux-gnu/libcrypto.a
Whereas, you need this:
$ locate libcrypto.a
/usr/lib/i386-linux-gnu/libcrypto.a
(I thought you could have both, but it turns out, on 12.04, it's impossible to have both because the packages conflict.)
You can install the i386 library like this:
sudo apt-get install libssl-dev:i386
Basically, you probably had the run-time libraries installed correctly, but you did not have the developer libraries.
The workaround which solved my problem:
I installed 32-bit version library
sudo apt-get install libssl-dev:i386
the 64-bit library was removed by that.
in the directory /usr/lib/i386-linux-gnu I found 32-bit version libcrypto.a and put it in /usr/lib32
Then I installed 64-bit library
sudo apt-get install libssl-dev
in the directory /usr/lib/x86_64-linux-gnu I found 64-bit version libcrypto.a and put it in /usr/lib64
in the Makefile of a project I adjusted paths /usr/lib32/libcrypto.a and /usr/lib64/libcrypto.a to be dependent on the corresponding command argument.
the project builds!
Related
I have a Mac which architecture is:
$ arch
arm64
(it supports x86_64 and aarch64).
And I have installed openssl library with brew tool. Now I try to build my application for x86_64 platform (it's Haskell application and the build script is large and complex, so I cannot show it here) and I get an error:
...
<command line>: dlopen(/MyWork/.stack/snapshots/x86_64-osx/b1d675598b9b6c5f516e03f82c45d01becd6003e6128005b2b4acb8628b0f350/9.2.5/lib/x86_64-osx-ghc-9.2.5/libHSHsOpenSSL-0.11.7.2-1JX1qBi8YfpGDjk1ra3OXq-ghc9.2.5.dylib, 0x0005): symbol not found in flat namespace '_DSA_free'
...
However, it works fine for aarch64 platform. After little research I see that my OpenSSL libraries are:
$ file /opt/homebrew/opt/openssl#3/3.0.7/lib/libssl.3.dylib
/opt/homebrew/opt/openssl#3/3.0.7/lib/libssl.3.dylib: Mach-O 64-bit dynamically linked shared library arm64
which seems that it is a library for arm64 and not x86_64, so maybe this is the reason of the error "symbol not found in flat namespace '_DSA_free'".
How to fix it? I guess I need to install the second openssl - for x86_64, I tried arch -x86_64 brew install openssl but I get:
Warning: openssl#3 3.0.7 is already installed and up-to-date.
To reinstall 3.0.7, run:
brew reinstall openssl#3
which makes sense - it is installed already (but for arm64).
How to fix/workaround this problem, so to be able to build the application for both platform while it depends on external libraries like openssl? Maybe there is a way to install openssl for both platform?
EDIT:
Currently I found 2 solutions:
to install libraries from sources setting prefix=/unique/folder/for/arch and to prefix ./configure ..., make, make install by arch -ARCH (where ARCH is x86_64 or arm64).
Another way is to have 2nd Homebrew, it's described here
Since upgrading to Yosemite I cannot compile with gfortran. Initially I was getting "segmentation fault 11", then I:
Updated to gcc v.5.0 from http://hpc.sourceforge.net/
Re-installed Xcode command line utilities v.6.1.1
After doing the above, I am able to compile very simple fortran programs but the more complex code that I run gives me the following error:
gfortran: error: libgfortran.spec: No such file or directory
But in fact, the libgfortran.spec file is located in /usr/local/lib
ls /usr/local/lib | grep gfortran
libgfortran.3.dylib
libgfortran.a
libgfortran.dylib
libgfortran.la
libgfortran.spec
All of the gcc binaries are located in /usr/local/bin
which gfortran
/usr/local/bin/gfortran
And my path seems to be OK
echo $PATH
/usr/local/lib:/usr/local/bin:/usr/local:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/lib:/usr/texbin:/Users/MattCooper/bin:/Applications/MRT/bin
I also tried re-installing gcc with homebrew:
brew install gcc
Error: gcc-4.9.2 already installed
To install this version, first 'brew unlink gcc'
However, I get v. 5.0 when I ask 'gcc --version':
gcc --version
gcc (GCC) 5.0.0 20141005 (experimental)
When I try to unlink or upgrade gcc with homebrew I get a permission denied error:
brew unlink gcc
Unlinking /usr/local/Cellar/gcc/4.9.2... Error: Permission denied - /usr/local/bin/c++-4.9
similarly
brew upgrade gcc
Permission denied - /usr/local/bin/c++-4.9
Finally
which gcc
/usr/local/bin/gcc
Please help. Many thanks ahead of time. Please let me know what I've forgotten to include.
I ended up solving the problem via homebrew. I can't pinpoint the exact source of the problem but it was related to the fact that I installed gcc v4.9 from http://hpc.sourceforge.net/, then somewhere along the way I re-installed and/or updated gcc with homebrew. Then, after upgrading to Yosemite, I installed gcc v5 from http://hpc.sourceforge.net/. Somewhere within that process, the binaries within /usr/local/bin and usr/local/lib were not linked properly.
The main clue was the Permission Denied error when trying to run 'brew upgrade gcc'. I found a solution here: Brew doctor says: "Warning: /usr/local/include isn't writable."
To fix, I used:
brew doctor
which returned a bunch of directories that were not writeable, for example usr/local/lib, thus brew was unable to ugrade gcc to the v5.0 and link everything.
I went through and issued:
sudo chown -R $USER /usr/local
and did this for all of the other non-writeable directories returned by 'brew doctor'. Then, I was able to use brew to ugrade gcc:
brew upgrade gcc
During the ugrade, homebrew returned an error that stated it could not finish the upgrade because there was already an existing gfortran file located in:
/usr/local/bin/gfortran
To fix, homebrew suggested I run:
brew -link gcc
at which point everything worked. Interesting (to me, because I don't fully understand all of this) when I ask brew to clean things up, I get:
brew cleanup
Warning: Skipping (old) /usr/local/Cellar/gcc/4.9.2 due to it being linked
There's some similar information located here: How to link to a new gcc version with brew?
Similar to that user, when I look in my cellar, I find two versions of gcc, but I'm not sure if I need both
ls /usr/local/Cellar/gcc
4.9.2 4.9.2_1
I had a similar issue with similar solution. It could not find this file:
gfortran: error: libgfortran.spec: No such file or directory
So my problem was that I had installed gcc through hpc.sourceforge.net and through homebrew. I had to uninstall the homebrew version
brew uninstall gcc
Then I had to reinstall the gcc from hpc.sourceforge.net
sudo tar -xvf gcc-4.9-bin.tar.gz -C /
This worked for me when I wanted to revert to gcc 4.9 from hpc.sourceforge.net, using Yosemite.
I am switching from contiki 2.7 to contiki 2.6 but have found that the sky-shell-exec example does not build with msp430-gcc 4.5.3 in contiki 2.6. To get around this while using contiki 2.6 I am trying to install msp430-gcc 4.6.3.
I have downloaded the deb package for 4.6.3 from http://helpdesk.jogjaprov.go.id/ubuntu/pool/universe/g/gcc-msp430/
and have used the following commands to try and install it:
sudo apt-get remove gcc*
sudo apt-get remove gcc-msp430
sudo dpkg --force-all -i ~/Downloads/gcc-msp430_4.6.3~mspgcc-20120406-3_i386.deb
sudo apt-get -f install
When I do a msp430-gcc --version it returns:
msp430-gcc (GCC) 4.6.3 20120301 (mspgcc LTS 20120406 unpatched)
So it seems that it has worked...
However, when I try to do a make sky-shell-exec.sky TARGET=sky in examples/sky-shell-exec/ I get two following error:
usr/lib/gcc/msp430/4.6.3/../../../../msp430/lib/mmpy-16/libc.a(vuprintf.o): In function `vuprintf':
/build/buildd/msp430-libc-20110612/src/./stdlib/vuprintf.c:387: undefined reference to `__udivmodsi4'
/build/buildd/msp430-libc-20110612/src/./stdlib/vuprintf.c:397: undefined reference to `__udivmodsi4'
collect2: ld returned 1 exit status
make: *** [sky-shell-exec.sky] Error 1
I thought at first thought that this might mean that my system has two different versions somehow tangled. But, I haven't been able to confirm or deny this.
I have check my version output with that found at http://www.george-smart.co.uk/wiki/Installing_Contiki and everything is the same except that my output says "... --build=i686-linux-gnu ..." instead of "... --build=x86_64-linux-gnu ..."
My questions are:
1) What am I doing wrong?
2) How does one switch msp430-gcc compilers from 4.5.3 to 4.6.3 to work with contiki 2.6?
Thanks!
Unfortunately I'm forced to use gcc-4.1 and I'm using debian wheezy. Since gcc-4.1 is not in repository I'm trying to build gcc from sources.
But I'm getting compiling error:
/usr/bin/ld: skipping incompatible /usr/lib/x86_64-linux-gnu/libc.so when searching for -lc
/usr/bin/ld: skipping incompatible /usr/lib/x86_64-linux-gnu/libc.a when searching for -lc
/usr/bin/ld: i386:x86-64 architecture of input file `/usr/lib/x86_64-linux-gnu/crti.o' is incompatible with i386 output
/usr/bin/ld: i386:x86-64 architecture of input file `/usr/lib/x86_64-linux-gnu/crtn.o' is incompatible with i386 output
It looks that ld is picking wrong version of libraries, but I checked my /usr/lib32 and /usr/lib/x86_64-linux-gnu/ and it contains those files:
/usr/lib32/libc.a
/usr/lib32/libc.so
/usr/lib32/crtn.o
/usr/lib32/crti.o
/usr/lib/x86_64-linux-gnu/libc.a
/usr/lib/x86_64-linux-gnu/libc.so
/usr/lib/x86_64-linux-gnu/crtn.o
/usr/lib/x86_64-linux-gnu/crti.o
And ld should have access to them
~$ echo $LIBRARY_PATH
/usr/lib/x86_64-linux-gnu:/usr/lib32/
So I have no idea where the problem is.
I managed to work around the problem.
Run configure with:
./configure --disable-multilib ...
But than I encountered another problem with makeinfo, if you have newer version >=4.10 than it might not be found by configure. So simple fix in generated makefile worked for me:
Change this line:
MAKEINFO = /home/lecopivo/Downloads/gcc412/gcc412/gcc-4.1.2/missing makeinfo
To this:
MAKEINFO = makeinfo
I found this helpful.
LD_LIBRARY_PATH is only for running programs already linked.
You probably need to set LDFLAGS when you configure gcc:
./configure LDFLAGS="-L/usr/lib32" .....
It might be LDFLAGS_FOR_HOST or LIBS or something like that though.
I had this problem recently and finally solved it this way:
ln -s /usr/lib32 /usr/lib/i386-linux-gnu
Notes:
I assumed you do not have /usr/lib/i386-linux-gnu directory in your 64bit linux. If this directory exists and is empty, please delete it and make the above link.
If the directory already exists and is not empty, you have to make links inside it for (32bit) libraries which cause build error one by one; e.g.:
ln -s /usr/lib32/crti.o /usr/lib/i386-linux-gnu/crti.o
ln -s /usr/lib32/crtn.o /usr/lib/i386-linux-gnu/crtn.o
...
If 32bit development libraries are not installed, you may have to install them first. I've searched different forums and found that installing following set of packages in ubuntu will provide them:
libc6-dev libc6-dev-i386
gcc-multilib g++-multilib
zlib1g-dev lib32z1-dev
libncurses5-dev lib32ncurses5-dev libncursesw5-dev lib32ncursesw5-dev
Also adjust LD_LIBRARY_PATH and LIBRARY_PATH variables so that they contain /usr/lib/i386-linux-gnu and /usr/lib/x86_64-linux-gnu (i.e. multiarch lib-dirs). I am not sure which one of above variables is effective, so I adjust both of them the same.
If you use ./configure --disable-multilib as it is frequently suggested on web, though gcc will be built, but when you want to use that gcc for compiling e.g. legacy grub, you probably get error of "gcc cannot build executable" (or such).
Optionally, you can make similar linking for these pair of libdirs:
ln -s /lib32 /lib/i386-linux-gnu
Doing so, I managed to compile gcc-3.4.6 in a Ubuntu 16.04.6-amd64 used for compiling old 32bit programs like SDL 1.2 and legacy GRUB4DOS 0.4.4.
Also take a look at my answer to similar (though opposite) error here.
Good luck.
I am attempting to build GCC-4.7.0 on a MacBook Pro running OS X 10.7.4. However, I am continuing to experience the same error:
configure: error: Building GCC requires GMP 4.2+, MPFR 2.3.1+ and MPC 0.8.0+.
This error occurred after running the following line:
./configure --prefix=/Users/jreese/Documents/school/edinburgh/project/local/
To get rid of this error I have tried the following actions:
Using homebrew I downloaded gmp-5.0.4, mpc-0.21, and mpfr-3.1.0. At this point I attempting to point to where gmp, mpc, and mpfr are located with the following command:
./configure --prefix=/Users/jreese/Documents/school/edinburgh/project/local/ --with-gmp=/usr/local/Cellar/ --with-mpfr=/usr/local/Cellar/ --with-mpc=/usr/local/Cellar/
However, this caused the same error. So, I tried pointing gcc to various locations around the Cellar directory:
./configure --prefix=/Users/jreese/Documents/school/edinburgh/project/local/ --with-gmp=/usr/local/Cellar/gmp/ --with-mpfr=/usr/local/Cellar/mpfr --with-mpc=/usr/local/Cellar/mpc/
./configure --prefix=/Users/jreese/Documents/school/edinburgh/project/local/ --with-gmp=/usr/local/Cellar/gmp/5.0.4/ --with-mpfr=/usr/local/Cellar/mpfr/3.1.0/ --with-mpc=/usr/local/Cellar/mpc/0.21/
./configure --prefix=/Users/jreese/Documents/school/edinburgh/project/local/ --with-gmp=/usr/local/Cellar/gmp/5.0.4/include/ --with-mpfr=/usr/local/Cellar/mpfr/3.1.0/include/ --with-mpc=/usr/local/Cellar/mpc/0.21/share/
In the end these all produced the same error. I then downloaded the versions of gmp, mpc, and mpfr linked from the gcc error message (found here: ftp://gcc.gnu.org/pub/gcc/infrastructure/). After building these from the source and running all the same configurations I am left with the same problem. The configurations I have tried with this installation are:
./configure --prefix=/Users/jreese/Documents/school/edinburgh/project/local/
./configure --prefix=/Users/jreese/Documents/school/edinburgh/project/local/ --with-gmp=/usr/local/ --with-mpfr=/usr/local/ --with-mpc=/usr/local/
./configure --prefix=/Users/jreese/Documents/school/edinburgh/project/local/ --with-gmp=/usr/local/include/ --with-mpfr=/usr/local/include/ --with-mpc=/usr/local/include/
Then I read somewhere that there could be a problem if I didn't explicitly set the configuration to run in 64-bit mode. So, I tried all of these configurations again with the added setting of 'CC=gcc -m64'. But this didn't change anything. If anyone has any ideas I would be greatly appreciative.
If you don't know how to build and properly direct GCC's configure to the libraries you can put them in the source tree of GCC itself:
/some/dir/source/gcc/[libstdc++|libgomp|gcc|libiberty|....]
/some/dir/source/gcc/gmp/[configure|...]
/some/dir/source/gcc/mpfr/[configure|...]
/some/dir/source/gcc/mpc/[configure|...]
So without the version number appended. Then just run GCC configure without any arguments related to GMP/MPC/MPFR.
I've faced the same issue and it was easily solved by installing the corresponding development packages: gmp-devel, mpfr-devel and libmpc-devel
Yigal
EasyBuild (a tool to make building software easier) can be of help here. It comes with a small easyconfig file that specifies which GCC version to build, and which features to enable (see for example https://github.com/hpcugent/easybuild/blob/master/easybuild/easyconfigs/g/GCC/GCC-4.7.0.eb).
Once you've downloaded EasyBuild and configured it, you can just run
$EBHOME/easybuild.sh myGCC.eb
with EBHOME set to the location where you unpacked EasyBuild, and myGCC.eb a copy of the example GCC easyconfig, which you modified to your needs.
This command will download the GCC source tarball for you and build/install it, after doing the same to any dependencies, for example GMP, MPFR and MPC, saving you a lot of headaches.
For more information on EasyBuild, see https://github.com/hpcugent/easybuild/wiki .