When installing i386-elf-gcc using aur. Install goes smoothly and no errors when I build. I added /usr/local/i386elfgcc/bin to my path and I am able to run the command. When I run a simple command such as i386-elf-gcc -g "kernel.cpp" -o "kernel.o", I am getting errors:
/usr/local/i386elfgcc/lib/gcc/i386-elf/10.2.0/../../../../i386-elf/bin/ld: cannot find crt0.o: No such file or directory
/usr/local/i386elfgcc/lib/gcc/i386-elf/10.2.0/../../../../i386-elf/bin/ld: cannot find -lg
/usr/local/i386elfgcc/lib/gcc/i386-elf/10.2.0/../../../../i386-elf/bin/ld: cannot find -lc
Reinstalling has not worked. What can I do to fix this? I am using Arch.
The original command was i386-elf-gcc -ffreestanding -m32 -g "kernel.cpp" -o "kernel.o"
I needed to add -nostdlib
Final command:
i386-elf-gcc -nostdlib -ffreestanding -m32 -g "kernel.cpp" -o "kernel.o"
Related
I'm trying to build Guile 2.2.
I've installed libunistring to /path/to/libunistring.
When I run
./configure --with-libunistring-prefix=/path/to/libunistring/
it fails, because it can't find libunistring.
configure:15954: checking for libunistring
configure:15976: gcc -std=gnu11 -o conftest -g -O2 conftest.c -lunistring >&5
conftest.c:158:21: fatal error: uniconv.h: No such file or directory
#include <uniconv.h>
How do I fix this?
The configure script is searching for /path/to/libunistring/lib64/. I believe you have only /path/to/libunistring/lib/.
% ln -s /path/to/libunistring/lib /path/to/libunistring/lib64
When attempting to compile GNU GCC 5.3.0 I encounter the following error when it tries to build libjavamath.la.
/bin/bash ../../../libtool --tag=CC --mode=link /home/borish/Downloads/gcc-build/./gcc/xgcc -B/home/borish/Downloads/gcc-build/./gcc/ -B/usr/local/x86_64-unknown-linux-gnu/bin/ -B/usr/local/x86_64-unknown-linux-gnu/lib/ -isystem /usr/local/x86_64-unknown-linux-gnu/include -isystem /usr/local/x86_64-unknown-linux-gnu/sys-include -W -Wall -Wmissing-declarations -Wwrite-strings -Wmissing-prototypes -Wno-long-long -Iyes/include -g -O2 -module -version-info 0:0:0 -no-undefined -Lyes/lib -lgmp -avoid-version -o libjavamath.la -rpath /usr/local/lib/../lib64/gcj-5.3.0-16 gnu_java_math_GMP.lo ../../../native/jni/classpath/jcl.lo
../../../libtool: line 5209: cd: yes/lib: No such file or directory
libtool: link: cannot determine absolute directory name of `yes/lib'
Makefile:403: recipe for target 'libjavamath.la' failed
This is on a Debian 8.4 system with GCC 4.9.2-10 installed. I believe I have satisfied all of the prerequisites, and Google wasn't been much help.
Any thoughts?
Update:
I used the following for running the configuration script:
../gcc-5.3.0/configure --disable-multilib --with-mpc --with-isl --with-mpfr --with-gmp
It sounds like you didn't run "configure" correctly. For example:
https://software.ecmwf.int/issues/browse/SUP-676
OK, I see a problem already, the "--with-jasper" option must point the
to the prefix of the "jasper" installation, for example
$./configure --with-jasper=/usr/local/jasper --with-png-support.
Otherwise the value "yes" is set as prefix..
For example, if you look here:
http://www.gnu.org/software/libc/manual/html_node/Configuring-and-compiling.html
you'll see that a flag like ‘--with-headers=directory’ REQUIRES YOU TO ENTER A DIRECTORY PATH. I suspect the same thing is happening with your "-with-mpc" etc.
SUGGESTION: clean your build directory, and (carefully!) re-run ./configure.
The culprit appears to be the --with-gmp, --with-mpc and --with-mpfr switches when initiating the configure script. I suspect since libgmp is a prerequisite for libmpc and libmpfr, a bug feature in the configure script will include the offending -I and -L directives. Inclusion of any of them will result in the following in the root Makefile
HOST_GMPLIBS = -Lyes/lib -lmpc -lmpfr -lgmp
HOST_GMPINC = -Iyes/include
I haven't confirmed this to be the case in any of the other Makefiles, but I suspect something similar is going on elsewhere which is what I ran into when it attempted to building libjavamath.la.
The work around is to omit those switches from the configure invocation. They should be included in any event since the configure script will fail if they aren't present on the host.
I am trying to compile a Python PCL module which builds some C++ source. I am getting this error:
$ python setup.py install
running install
running build
running build_py
running build_ext
skipping 'pcl/_pcl.cpp' Cython extension (up-to-date)
building 'pcl._pcl' extension
/usr/bin/clang -fno-strict-aliasing -fno-common -dynamic -g -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -I/Library/Python/2.7/site-packages/numpy/core/include -I/usr/local/Cellar/pcl/HEAD/include/pcl-1.8 -I/usr/local/Cellar/eigen/3.2.3/include/eigen3 -I/usr/local/Cellar/pcl/HEAD/include/pcl-1.8 -I/usr/local/Cellar/flann/1.8.4/include -I/usr/local/Cellar/pcl/HEAD/include/pcl-1.8 -I/Library/Frameworks/Python.framework/Versions/2.7/include/python2.7 -c pcl/_pcl.cpp -o build/temp.macosx-10.6-intel-2.7/pcl/_pcl.o
pcl/_pcl.cpp:244:10: fatal error: 'boost/smart_ptr/shared_ptr.hpp' file not
found
#include "boost/smart_ptr/shared_ptr.hpp"
^
1 error generated.
error: command '/usr/bin/clang'
For whatever reason clang isn't looking in /usr/local/include where it most definitely would find the boost headers. As you can see it is linking all the other dependencies fine. What can I add that so clang will find boost?
On OSX 10.10, nothing fancy happening anywhere. Boost was probably installed by homebrew, but the files are all in /usr/local/include/boost as I'd expect.
Check the output of /usr/bin/clang++ -v some_test_file.cpp but chances are /usr/local/include isn't in the standard search path of the compiler.
You'll need to add -I/usr/local/include to CXXFLAGS or CPPFLAGS or whatever appropriate place in your build script or environment. It seems the python build script is failing to properly detect Boost.
If the above is not true (and /usr/local/include does show up in the output), make sure /usr/local/include/boost/smart_ptr/shared_ptr.hpp exists.
Okay, so, I switched from ubuntu 12.04 64-bit to 32-bit and installed build-essential.
I then compiled and installed GMP-5.0.5, MPFR-3.1.1, MPC-1.0, ISL-0.10 and CLOOG-0.17.0. I checked out a copy of the main gcc trunk and attempted to build it with the following configure line (from a separate directory):
../svnsrc/configure --prefix=/usr/GCC/svn --enable-__cxa_atexit --with-plugin-ld=/usr/bin/ld.gold --enable-threads=posix --enable-werror --enable-build-with-cxx --with-gmp=/usr/GCC/prereq/svn --with-mpfr=/usr/GCC/prereq/svn --with-mpc=/usr/GCC/prereq/svn --with-isl=/usr/GCC/prereq/svn --with-cloog=/usr/GCC/prereq/svn --enable-languages=c,c++
Configure ran fine and so I ran make && make check. This ran fine for a while, but then it failed with the following error:
/home/matt/GCC/svnbuild/./gcc/xgcc -B/home/matt/GCC/svnbuild/./gcc/ -B/usr/GCC/svn/i686-pc-linux-gnu/bin/ -B/usr/GCC/svn/i686-pc-linux-gnu/lib/ -isystem /usr/GCC/svn/i686-pc-linux-gnu/include -isystem /usr/GCC/svn/i686-pc-linux-gnu/sys-include -g -O2 -O2 -g -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -fpic -mlong-double-80 -g -DIN_LIBGCC2 -fbuilding-libgcc -fno-stack-protector -fpic -mlong-double-80 -I. -I. -I../.././gcc -I../../../svnsrc/libgcc -I../../../svnsrc/libgcc/. -I../../../svnsrc/libgcc/../gcc -I../../../svnsrc/libgcc/../include -I../../../svnsrc/libgcc/config/libbid -DENABLE_DECIMAL_BID_FORMAT -DHAVE_CC_TLS -DUSE_TLS -o _muldi3.o -MT _muldi3.o -MD -MP -MF _muldi3.dep -DL_muldi3 -c ../../../svnsrc/libgcc/libgcc2.c -fvisibility=hidden -DHIDE_EXPORTS
In file included from /usr/include/stdio.h:28:0,
from ../../../svnsrc/libgcc/../gcc/tsystem.h:88,
from ../../../svnsrc/libgcc/libgcc2.c:29:
/usr/include/features.h:324:26: fatal error: bits/predefs.h: No such file or directory
#include <bits/predefs.h>
^
compilation terminated.
make[3]: *** [_muldi3.o] Error 1
make[3]: Leaving directory `/home/matt/GCC/svnbuild/i686-pc-linux-gnu/libgcc
I looked around, but everything I seemed to find was that this error was caused on x86_64, by not installing gcc-multilib, because Ubuntu and Debian use the mutiarch system, separating the libraries. Okay, fine...but I'm using i686, so why would I need the 64-bit libraries? Any help would be appreciated. Thanks.
Try doing a
sudo apt-get install gcc-multilib
I don't think that installing a 32-bit system changes the architecture of your computer, because your computer will always be a 64-bit machine. Installing the 64-bit version of Ubuntu should only give better multi-core performance. Since your computer is still a 64-bit computer, you probably need a C compiler that will compile on 64-bit machines. Hence the gcc-multilib. I think.
the gcc-multilib trick didn't work out for me. Instead, setting this in the build environment did the trick:
C_INCLUDE_PATH=/usr/include/$(gcc -print-multiarch)
I am having trouble installing pyipopt on ubuntu 12.04. During linking, I receive the error:
/usr/bin/ld: cannot find -lcoinhsl
Even though I know that this library is installed and the .so and .la files are available in /home/mostafa/MyBuilds/CoinIpopt/build/lib/
does anyone have a solution for this?
below is the complete return of running setup.py build:
root#ubuntu:~/MyBuilds/pyipopt# sudo python setup.py build
running build
running build_ext
building 'pyipopt' extension
gcc -pthread -fno-strict-aliasing -DNDEBUG -g -fwrapv -O2 -Wall -Wstrict-prototypes -fPIC -I/usr/lib/python2.7/dist-packages/numpy/core/include -I/home/mostafa/MyBuilds/CoinIpopt/build/include/coin/ -I/usr/include/python2.7 -c src/callback.c -o build/temp.linux-x86_64-2.7/src/callback.o
gcc -pthread -fno-strict-aliasing -DNDEBUG -g -fwrapv -O2 -Wall -Wstrict-prototypes -fPIC -I/usr/lib/python2.7/dist-packages/numpy/core/include -I/home/mostafa/MyBuilds/CoinIpopt/build/include/coin/ -I/usr/include/python2.7 -c src/pyipopt.c -o build/temp.linux-x86_64-2.7/src/pyipopt.o
src/pyipopt.c: In function ‘set_intermediate_callback’:
src/pyipopt.c:452:15: warning: variable ‘myowndata’ set but not used [-Wunused-but-set-variable]
gcc -pthread -shared -Wl,-O1 -Wl,-Bsymbolic-functions -Wl,-Bsymbolic-functions -Wl,-z,relrobuild/temp.linux-x86_64-2.7/src/callback.o build/temp.linux-x86_64-2.7/src/pyipopt.o -L/home/mostafa/MyBuilds/CoinIpopt/build/lib/ -lipopt -lblas -lcoinhsl -lcoinmetis -llapack -ldl -lm -o build/lib.linux-x86_64-2.7/pyipopt.so -Wl,--rpath -Wl,/home/mostafa/MyBuilds/CoinIpopt/build/lib/
/usr/bin/ld: cannot find -lcoinhsl
collect2: ld returned 1 exit status
error: command 'gcc' failed with exit status 1
-Ldir
Add directory dir to the list of directories to be searched for -l.
You may install your coinhsl library in one of your standard libraries directories and run 'ldconfig` before doing your ppyipopt install
I had a similar problem with another library and the reason why it didn't found it, was that I didn't run the make install (after running ./configure and make) for that library. The make install may require root privileges (in this case use: sudo make install). After running the make install you should have the so files in the correct folder, i.e. here /usr/local/lib and not in the folder mentioned by you.
you can add the Path to coinhsl lib to LD_LIBRARY_PATH variable. May be that will help.
export LD_LIBRARY_PATH=/xx/yy/zz:$LD_LIBRARY_PATH
where /xx/yy/zz represent the path to coinhsl lib.