I'm trying to build top(1) from sources under FreeBSD 10.1-RELEASE (clang version 3.4.1).
# fetch http://www.unixtop.org/dist/top-3.7.tar.gz
# tar -xzf top-3.7.tar.gz
# cd top-3.7
# ./configure
# make
# make install
Compilation goes without errors, but the binary compiled don't work, giving me error as below:
# top
kvm_open: kvm_nlist: No such file or directory
kvm_open: kvm_nlist: No such file or directory
kvm_open: kvm_nlist: No such file or directory
kvm_open: kvm_nlist: No such file or directory
kvm_open: kvm_nlist: No such file or directory
kvm_open: kvm_nlist: No such file or directory
kvm_open: kvm_nlist: No such file or directory
kernel: no symbol named `_cp_time'
What is my mistake, how to make it work? I have tried with version 3.6 and 3.7, with clang and gcc, under 10.1-RELEASE and 8.4-RELEASE with the same results.
I guess it's a sign of FreeBSD support in upstream top being rather obsolete. Which is kind of obvious, since FreeBSD is using its own fork.
Perhaps it would be easier to port the specific features you need from upstream to FreeBSD version, instead of the other way around?
It looks like the version you used is not compatible with the version of FreeBSD you run.
The sourcecode for top(1) is found in /usr/src/contrib/top
The Makefile glue is in /usr/src/usr.bin/top
Related
The make instruction is not finding the libraries required for compilation. They are in other folder than the usual /usr/include folder.
I'm complying a simulation software called magnum.fe I already installed all the required dependencies (FEniCS = 1.5
CMake >= 2.8
SWIG >= 2.0
G++ >= 4.0) and started to run make as the instructions suggest.
$ cd /path/to/magnum.fe
$ mkdir build
$ cd build
$ cmake ..
$ make
$ sudo make install
But when running make I get the following error:
/usr/include/petscsys.h:136:12: fatal error: petsc/mpiuni/mpi.h: No such file or directory
136 | # include <petsc/mpiuni/mpi.h>
| ^~~~~~~~~~~~~~~~~~~~
compilation terminated.
The files do exist, but in other folder: /home/myusername/bin/petsc/include/mpiuni/mpi.h
I compiled petsc on /home/myusername/bin/petsc/ with the following instruction:
$ ./configure --with-cc=gcc --with-cxx=g++ --with-fc=gfortran --download-mpich --download-fblaslapack
$ make all check
It compiled it sucessfully but I couldn't get the magnum.fe compilation to finish.
I tried moving each header file to /usr/include but now I'm stuck on if moving the whole petsc directory into this folder. It must be a more elegant way to do it.
Thanks
I've made it!
There are two options available:
Specify the libraries to use with the make command editing the MAKEfile, use the variable LDLIBS to set it up. Detailed usage in here: https://web.archive.org/web/20070723140628/http://arco.inf-cr.uclm.es/~david.villa/doc/repo/make/make.html#AEN36
or
Create symbolic links pointing to /usr/include. In my case I used:
ln -s /home/myusername/bin/petsc/include/* /usr/include
I have a project which uses libibverbs. I have to compile this project on a server to run it there. The server has libibverbs installed system-wide, but unfortunately it doesn't support a feature which I need.
I decided to compile and use my own version of libibverbs, which has the corresponding feature. So I compiled the library, installed it to my home directory, and updated following environment variables: PATH, LD_LIBRARY_PATH, C_INCLUDE_PATH, LIBRARY_PATH, CPLUS_INCLUDE_PATH
Now I have to compile my project. First I call configure and it fails with following error message:
conftest.c:(.text.startup+0x7): undefined reference to `ibv_open_xrc_domain'
This is the symbol, which is missing in the system-wide version, but is present in the version I installed. First entry in LIBRARY_PATH is the path to the new libibversion, so I expected it is going to be used first, but it seems that the old version is used anyway.
Compilation command which ./configure uses, contains flag -L/libibverbs/1.1.4/lib, which points to the directory with the new library version. This flag goes just after -L/usr/lib/../lib64 which point to the directory, with system-wide libibverbs
If I put -L with new version in the end of command, the conftest compiles successfully.
To be clear following fails: https://gist.github.com/planetA/a421669269b14e69026c53f56fa45b2b
And following works:
https://gist.github.com/planetA/3b0e22bf6aca3a1c67f30bfa3666d9a8
Could you help me to enforce picking the new version of the library in a way that configure catches it?
LD_LIBRARY_PATH specifies directories to be searched, before the
defaults, for a library that is to be loaded in a process at runtime.
It does not affect the directories that are searched for a library
in order to link it at buildtime.
The linker searches for libraries in the directories that are specified
with the -Ldir option in its commandline, before it searches its
default directories. Your configure script tests whether it can find a libibverbs library in the linker's search directories that defines the function
ibv_open_xrc_domain, and fails because it cannot. The value of LD_LIBRARY_PATH does
not matter to this test.
For GNU make, the -L-options it should pass to the linker
are conventionally specified in the environment variable LDFLAGS. GNU autoconf - which
generates your configure script - follows this convention. autoconf generates
the configure script from the project's configure.ac file.
So, if your want your modified package to generate a generate a configure
script such that running ./configure will in turn generate makefiles
in which -L/my/library/version/is/here is passed to the linker then
you need to modify the project's configure.ac like:
LDFLAGS="$LDFLAGS -L/my/library/version/is/here"
and you need to do this in the configure.ac before it runs the test for
the libibverbs library. After making this change you will need to reconfigure
the package by running autoreconf in the project directrory, to regenerate
the configure script.
If you don't want to change the configure.ac like this then you can achieve the same
effect by:
./configure LDFLAGS="$LDFLAGS -L/my/library/version/is/here"
or:
export LDFLAGS="$LDFLAGS -L/my/library/version/is/here"
... # in same shell or a subshell
./configure
Then until the next time you run the configure script the project's makefiles
will pass -L/my/library/version/is/here to the linker. But the next time
you run ./configure you must remember to set LDFLAGS in the same way, or
the regenerated makefiles will revert to the default behaviour.
I have an OSX 10.7 computer with a non-administrator account, and was attempting to install the pre-compiled versions of gcc and g++ found here. I've attempted to use the answers presented in these questions (three different links) to compile some code with g++, to confusing avail. I have a folder structure like this:
~/code/:
usr/:
local/:
bin/ (3.6MB)
include/ (8.6MB)
lib/ (51MB)
libexec/ (49MB)
share/ (16MB)
c++/:
source/ (contains .cpp files)
g++ -v returns this:
code USER$ usr/local/bin/g++ -v
Using built-in specs.
COLLECT_GCC=usr/local/bin/g++
COLLECT_LTO_WRAPPER=/Users/USERNAME/code/usr/local/bin/../libexec/gcc/ x86_64-apple-darwin11.4.0/4.7.1/lto-wrapper
Target: x86_64-apple-darwin11.4.0
Configured with: ../gcc-4.7.1/configure --enable-languages=fortran
Thread model: posix
gcc version 4.7.1 (GCC)
An attempt at compiling a file that "#include"s only iostream:
$ usr/local/bin/g++ c++/source/test.cpp -o ex6
In file included from /Users/USERNAME/code/usr/local/bin/../lib/gcc/x86_64-apple-darwin11.4.0/4.7.1/../../../../include/c++/4.7.1/bits/postypes.h:42:0,
from /Users/USERNAME/code/usr/local/bin/../lib/gcc/x86_64-apple-darwin11.4.0/4.7.1/../../../../include/c++/4.7.1/iosfwd:42,
from /Users/USERNAME/code/usr/local/bin/../lib/gcc/x86_64-apple-darwin11.4.0/4.7.1/../../../../include/c++/4.7.1/ios:39,
from /Users/USERNAME/code/usr/local/bin/../lib/gcc/x86_64-apple-darwin11.4.0/4.7.1/../../../../include/c++/4.7.1/ostream:40,
from /Users/USERNAME/code/usr/local/bin/../lib/gcc/x86_64-apple-darwin11.4.0/4.7.1/../../../../include/c++/4.7.1/iostream:40,
from c++/source/ex6.cpp:1:
/Users/USERNAME/code/usr/local/bin/../lib/gcc/x86_64-apple-darwin11.4.0/4.7.1/../../../../include/c++/4.7.1/cwchar:46:19: fatal error: wchar.h: No such file or directory
compilation terminated.
I tried compiling with some flags recommended in one of the links mentioned, like this: (with all combinations of "usr/" to "usr/local/include/" and "usr/" to "/usr/local/lib" giving the same result (which is also the same as using no flags).
$ /Users/USERNAME/code/usr/local/bin/g++ source/ex6.cpp -I/Users/USERNAME/code/usr/local/include/ -L/Users/USERNAME/code/usr/local/lib/In file included from /Users/USERNAME/code/usr/local/bin/../lib/gcc/x86_64-apple-darwin11.4.0/4.7.1/../../../../include/c++/4.7.1/bits/postypes.h:42:0,
from /Users/USERNAME/code/usr/local/bin/../lib/gcc/x86_64-apple-darwin11.4.0/4.7.1/../../../../include/c++/4.7.1/iosfwd:42,
from /Users/USERNAME/code/usr/local/bin/../lib/gcc/x86_64-apple-darwin11.4.0/4.7.1/../../../../include/c++/4.7.1/ios:39,
from /Users/USERNAME/code/usr/local/bin/../lib/gcc/x86_64-apple-darwin11.4.0/4.7.1/../../../../include/c++/4.7.1/ostream:40,
from /Users/USERNAME/code/usr/local/bin/../lib/gcc/x86_64-apple-darwin11.4.0/4.7.1/../../../../include/c++/4.7.1/iostream:40,
from source/ex6.cpp:1:
/Users/USERNAME/code/usr/local/bin/../lib/gcc/x86_64-apple-darwin11.4.0/4.7.1/../../../../include/c++/4.7.1/cwchar:46:19: fatal error: wchar.h: No such file or directory
compilation terminated.
In short, I'm having trouble understanding what the answers in the links provided are saying to do. I saw reference to a specs file, which I could find no specific information for, and "-Wl,-rpath,$(DEFAULT_LIB_INSTALL_PATH)", for which I couldn't figure out what I was supposed to substitute for "DEFAULT_LIB_INSTALL_PATH".
What should I do to point the downloaded g++ compiler to its own files without placing them in their default location, as I do not have administrative capabilities on this account?
I will provide any information as necessary.
It looks like you don't have required header files. You need to install Command Line Tools from Apple Developers site (free registration needed). The problem is that you don't have administrator account. I suggest that you ask the administrator to install the tools for you. If it is not possible you could try to extract the contents of downloaded package (DevSDK.pkg) to your local directory (Pacifist can do that) and pass the path with the missing headers to your compiler. I haven't tried that though.
This is my first time with scons and compiling in general.
This application had a problem which was fixed by this guy here. Now I want to apply that fix manually but only recompile that specific bit of code. So:
followed the instructions and downloaded everything locally.
modified the 3 files accordingly
attempted to recompile:
cd titanium_desktop/modules/ti.Network
scons
scons: *** No SConstruct file found.
File "C:\Python25\Scripts\..\Lib\site-packages\scons-1.2.0\
SCons\Script\Main.py", line 826, in _main
What am I doing wrong and what should I be doing instead?
The SConstruct file is the main SCons build script. Without it, SCons doesnt konw what to do.
I see from your commands that you are trying to do a build of a sub-directory which has a SConscript file, but not a SConstruct file. In this case, you need to tell SCons where the SConstruct file is. The most common way to do this is as follows:
# scons -u
This tells SCons to traverse up the directory hierarchy until it finds the SConstruct file.
You can find more SCons command line options here.
I have followed the instructions at Cross linux from scratch for powerpc, but I can't get past the gcc-final stage due to an ld error crti.o: no such file or directory.
My tool chain is separated into two directories: /opt/builder/tools and /opt/builder/cross-tools, with Linux headers and eglibc in the first and cross-utilities in the second. Also I have created links /tools and /cross-tools for those directories.
I have tried /cross-tools/bin/powerpc-unknown-linux-gcc -print-search-path and there was a directory /opt/builder/tools/lib there in the "libraries" section. But gcc passes names of crt....o objects to ld without directory prefixes (I have used strace to find it out).
The crt....o files are good because, when I copied them to the directory with hello.c and compiled it, everything was ok.
Could you give some advice?
Thanks in advance,
Sergey Naumov.
The libc-provided crt files should be in $ROOT/$TARGET/lib/ (i.e., The gcc-compiled crt files will later be installed in $ROOT/lib/gcc/$TARGET/$GCC_VERSION/.