In the process of building a set of ARM tools. I have used these steps many times before. I have tried the same configure/make in the "newlib-2.5.0.20170922" and "newlib-2.5.0.20170922" directories. Still get the error. I also tried my steps as super-user. No change. In the past building Newlib has always been a problem. Can somebody assist?
tar -xf newlib-2.5.0.20170922.tar.gz
cd newlib-2.5.0.20170922.armbuild
../newlib-2.5.0.20170922/configure --target=arm-none-eabi --prefix=/usr/local --enable-interwork --enable-multilib --with-gnu-as --with-gnu-ld --disable-nls --disable-werror
make
The build proceeds for quite some time until the following error. I examine the only two directories "cpu_init" and "semihv2m".
$ pwd
/usr/local/src/newlib/newlib-2.5.0.20170922.armbuild/arm-none-eabi/libgloss
$ ls
config.log librdimon.a rdimon-ftruncate.o redboot-syscalls.o
config.status librdpmon.a rdimon-_kill.o semihv2m
cpu-init linux-crt0.o rdimon-libcfunc.o syscalls.o
_exit.o linux-syscalls0.o rdimon-syscalls.o trap.o
ftruncate.o linux-syscalls1.o rdimon-trap.o truncate.o
_kill.o Makefile rdimon-truncate.o
libcfunc.o rdimon-crt0.o rdpmon-crt0.o
libgloss-linux.a rdimon-_exit.o redboot-crt0.o
$ ls -l cpu-init
total 8
-rw-rw-r-- 1 ron ron 3718 Nov 20 06:05 Makefile
-rw-rw-r-- 1 ron ron 536 Nov 20 06:05 rdimon-aem.o
$ ls -l semihv2m
config.log config.status Makefile
$ ls -l semihv2m
total 40
-rw-rw-r-- 1 ron ron 393 Nov 20 06:05 config.log
-rwxrwxr-x 1 ron ron 32936 Nov 20 06:05 config.status
-rw-rw-r-- 1 ron ron 0 Nov 20 06:05 Makefile
$ cat semihv2m/config.log
## ---------------------- ##
## Running config.status. ##
## ---------------------- ##
This file was extended by config.status, which was
generated by GNU Autoconf 2.68. Invocation command line was
CONFIG_FILES =
CONFIG_HEADERS =
CONFIG_LINKS =
CONFIG_COMMANDS =
$ config.status
config.status:805: error: cannot find input file: `cpu-init/Makefile.in'
End of make output:
config.status: error: cannot find input file: `cpu-init/Makefile.in'
sed: can't read Makefile: No such file or directory
make[6]: Entering directory '/usr/local/src/newlib/newlib- 2.5.0.20170922.armbuild/arm-none-eabi/libgloss/arm/semihv2m'
make[6]: *** No rule to make target 'all'. Stop.
make[6]: Leaving directory '/usr/local/src/newlib/newlib-2.5.0.20170922.armbuild/arm-none-eabi/libgloss/arm/semihv2m'
make[5]: *** [../../../../newlib-2.5.0.20170922/libgloss/arm/../multi-build.in:6: multi-do] Error 1
make[5]: Leaving directory '/usr/local/src/newlib/newlib-2.5.0.20170922.armbuild/arm-none-eabi/libgloss/arm'
make[4]: *** [Makefile:214: all-multi] Error 2
make[4]: Leaving directory '/usr/local/src/newlib/newlib-2.5.0.20170922.armbuild/arm-none-eabi/libgloss/arm'
make[3]: *** [Makefile:144: all] Error 2
make[3]: Leaving directory '/usr/local/src/newlib/newlib-2.5.0.20170922.armbuild/arm-none-eabi/libgloss/arm'
make[2]: *** [Makefile:132: stmp-bsp] Error 2
make[2]: Leaving directory '/usr/local/src/newlib/newlib-2.5.0.20170922.armbuild/arm-none-eabi/libgloss'
make[1]: *** [Makefile:9528: all-target-libgloss] Error 2
make[1]: Leaving directory '/usr/local/src/newlib/newlib-2.5.0.20170922.armbuild'
make: *** [Makefile:879: all] Error 2
I ran into the same issue.
It seems to be resolved in the latest version in the git repository.
Related
I was running a make to produce a cross-compiled Linux kernel, with --target=mips-buildroot-linux-uclibc, --host=mips-linux, CC= mipsel-buildroot-linux-gnu-gcc, --build=x86_64-linux-gnu.
The build environment is Ubuntu 20.04.
I encountered the following error:
Makefile:147: target 'install-libmxml.so.1.4' does not exist
/usr/bin/install -c -d /home/minipc/econet/lib_install
/bin/rm -f libmxml.so
/bin/ln -s /home/minipc/econet/apps/public/mxml-2.4/libmxml.so.1.4 libmxml.so
/bin/rm -f libmxml.so.1
/bin/ln -s /home/minipc/econet/apps/public/mxml-2.4/libmxml.so.1.4 libmxml.so.1
/bin/rm -f /home/minipc/econet/lib_install/libmxml.so*
/bin/cp -rf libmxml.so* /home/minipc/econet/lib_install
/bin/cp: cannot open 'libmxml.so' for reading: Too many levels of symbolic links
make[1]: *** [Makefile:153: install-libmxml.so.1.4] Error 1
The Makefile snippet code is:
146 install-libmxml.so.1.4:
147 $(INSTALL_DIR) $(LIB_INSTALL_DIR)
148 $(RM) libmxml.so
149 $(LN) $(shell pwd)/libmxml.so.1.4 libmxml.so
150 $(RM) libmxml.so.1
151 $(LN) $(shell pwd)/libmxml.so.1.4 libmxml.so.1
152 $(RM) $(LIB_INSTALL_DIR)/libmxml.so*
153 $(CP) libmxml.so* $(LIB_INSTALL_DIR)
And I checked that symbolic link libmxml.so and libmxml.so.1 have been correctly created.
lrwxrwxrwx 1 minipc minipc 55 Aug 13 22:35 libmxml.so -> /home/minipc/econet/apps/public/mxml-2.4/libmxml.so.1.4*
lrwxrwxrwx 1 minipc minipc 55 Aug 13 22:35 libmxml.so.1 -> /home/minipc/econet/apps/public/mxml-2.4/libmxml.so.1.4*
-rwxrwxr-x 1 minipc minipc 30084 Aug 13 22:35 libmxml.so.1.4*
And I tried the following in the direcotry /home/minipc/econet/apps/public/mxml-2.4
$ /bin/cp -rf libmxml.so* /home/minipc/econet/lib_install
It created the desired result with no any warning or error reported.
So I wonder why it reported error in Make process?
It was caused by this recipe:
$(CP) libmxml.so* $(LIB_INSTALL_DIR)
It maybe that coping two symbolic links to the same file to the same directory simultaneously lead to error. I found a workaround:
154 $(CP) libmxml.so.1.4 $(LIB_INSTALL_DIR)
155 $(LN) $(LIB_INSTALL_DIR)/libmxml.so.1.4 $(LIB_INSTALL_DIR)/libmxml.so
156 $(LN) $(LIB_INSTALL_DIR)/libmxml.so.1.4 $(LIB_INSTALL_DIR)/libmxml.so.1
First, copy the real file to the dir, then create 2 symbolic links in the dir one by one.
That's it. No errors reported any more.
I am trying to run a simple tcl script with tclsh8.6 that I compiled from source using a musl toolchain on x86_64 Debian.
The script, hello.tcl, looks like this:
puts hello
and when I try to run it I get the following error:
$ /usr/local/x86_64-linux-musl/bin/tclsh8.6 hello.tcl
-bash: /usr/local/x86_64-linux-musl/bin/tclsh8.6: No such file or directory
The necessary tcl libraries and include files are all installed to the prefix /usr/local/x86_64-linux-musl. The binary also exists:
$ ls -l /usr/local/x86_64-linux-musl/bin/tclsh8.6
-rwxr-xr-x 1 root root 8328 Nov 15 12:18 /usr/local/x86_64-linux-musl/bin/tclsh8.6
$ ldd /usr/local/x86_64-linux-musl/bin/tclsh8.6
linux-vdso.so.1 (0x00007ffd04718000)
libtcl8.6.so => /usr/local/x86_64-linux-musl/lib/libtcl8.6.so (0x00007f005981e000)
libc.so => /usr/local/x86_64-linux-musl/lib/libc.so (0x00007f0059587000)
I would like to keep things musl based, so I am trying to avoid a potential solution I found elsewhere, which is to reinstall tcl or tcl-dev with apt-get.
What is causing this error? Any guidance/help is greatly appreciated. Thanks :)
EDIT
As requested by some of the comments here is some additional information.
The output of the file command:
$ file /usr/local/x86_64-linux-musl/bin/tclsh8.6
/usr/local/x86_64-linux-musl/bin/tclsh8.6: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib/ld-musl-x86_64.so.1, not stripped
The output of the strace command:
strace /usr/local/x86_64-linux-musl/bin/tclsh8.6 hello.tcl
execve("/usr/local/x86_64-linux-musl/bin/tclsh8.6", ["/usr/local/x86_64-linux-musl/bin"..., "hello.tcl"], 0x7fffb8c5b278 /* 19 vars */) = -1 ENOENT (No such file or directory)
strace: exec: No such file or directory
+++ exited with 1 +++
After seeing this output, I checked to see if the loader/interpreter existed at /lib and it didn't. To fix this, I ran:
$ sudo ln -s /usr/local/x86_64-linux-musl/lib/ld-musl-x86_64.so.1 /lib/ld-musl-x86_64.so.1
That gave me a different error when I ran tclsh8.6:
$ /usr/local/x86_64-linux-musl/bin/tclsh8.6 hello.tcl
-bash: /usr/local/x86_64-linux-musl/bin/tclsh8.6: Permission denied
Running it with sudo gives the same thing:
$ sudo /usr/local/x86_64-linux-musl/bin/tclsh8.6 hello.tcl
sudo: unable to execute /usr/local/x86_64-linux-musl/bin/tclsh8.6: Permission denied
The permissions on the interpreter and script are as follows:
$ ls -l /usr/local/x86_64-linux-musl/bin/tclsh8.6
-rwxr-xr-x 1 root root 8328 Nov 15 13:34 /usr/local/x86_64-linux-musl/bin/tclsh8.6
$ ls -l hello.tcl
-rwxr-xr-x 1 user user 11 Nov 15 12:44 hello.tcl
Hopefully this new information helps a bit more.
EDIT 2
More permission information :)
$ ls -l /lib/ld-musl-x86_64.so.1
lrwxrwxrwx 1 root root 52 Nov 16 10:04 /lib/ld-musl-x86_64.so.1 -> /usr/local/x86_64-linux-musl/lib/ld-musl-x86_64.so.1
$ ls -l /usr/local/x86_64-linux-musl/lib/ld-musl-x86_64.so.1
lrwxrwxrwx 1 root root 12 Nov 15 12:02 /usr/local/x86_64-linux-musl/lib/ld-musl-x86_64.so.1 -> /lib/libc.so
$ $ ls -l /lib/libc.so
-rw-r--r-- 1 root root 246 Nov 14 15:15 /lib/libc.so
And here is the contents of /lib/libc.so:
/* GNU ld script
Use the shared library, but some functions are only in
the static library, so try that secondarily. */
OUTPUT_FORMAT(elf64-x86-64)
GROUP ( //lib/libc.so.6 //lib/libc_nonshared.a AS_NEEDED ( //lib/ld-linux-x86-64.so.2 ) )
It is a linker script, which if you make executable fails and says the library is corrupted.
With the help of #Shawn I was able to figure out my problem.
tclsh8.6 was looking for the program interpreter at /lib/ld-musl-x86_64.so.1 which didn't exist - I guess when I was installing musl-cross-make it didn't set this up. To fix this problem, I simply symlinked from where ld-musl-x86_64.so.1 was located to lib:
$ sudo ln -s /usr/local/x86_64-linux-musl/lib/ld-musl-x86_64.so.1 /lib/ld-musl-x86_64.so.1
However, I still was getting an error, but this time it was a permissions error:
$ /usr/local/x86_64-linux-musl/bin/tclsh8.6 hello.tcl
-bash: /usr/local/x86_64-linux-musl/bin/tclsh8.6: Permission denied
It turns out that ld-musl-x86_64.so.1 ended up being a symlink that resolved to /lib/libc.so which is a linker script and not the executable DSO that we want. I changed this symlink accordingly:
sudo ln -fs /usr/local/x86_64-linux-musl/lib/libc.so /usr/local/x86_64-linux-musl/lib/ld-musl-x86_64.so.1
After that, I could execute my script and everything worked like a charm! :)
On Arch Linux, when I build something, ld complains can't find curses library:
/usr/bin/ld: cannot find -lcurses
collect2: error: ld returned 1 exit status
But my /usr/lib indeed contains curses related library:
# ls -lt /usr/lib/libcurse*
lrwxrwxrwx 1 root root 13 May 29 14:50 /usr/lib/libcurses.so -> libncurses.so
-rw-r--r-- 1 root root 18 May 29 14:50 /usr/lib/libcursesw.so
# ls -lt /usr/lib/libncurse*
-rw-r--r-- 1 root root 20 May 29 14:50 /usr/lib/libncurses++.so
lrwxrwxrwx 1 root root 18 May 29 14:50 /usr/lib/libncurses++w.so -> libncurses++w.so.6
lrwxrwxrwx 1 root root 20 May 29 14:50 /usr/lib/libncurses++w.so.6 -> libncurses++w.so.6.0
-rwxr-xr-x 1 root root 77264 May 29 14:50 /usr/lib/libncurses++w.so.6.0
-rw-r--r-- 1 root root 18 May 29 14:50 /usr/lib/libncurses.so
-rwxr-xr-x 1 root root 444776 May 29 14:50 /usr/lib/libncursesw.so.6.0
lrwxrwxrwx 1 root root 16 May 29 14:50 /usr/lib/libncursesw.so -> libncursesw.so.6
lrwxrwxrwx 1 root root 18 May 29 14:50 /usr/lib/libncursesw.so.6 -> libncursesw.so.6.0
We can see libcurses.so points to libncurses.so, and libncurses.so is like this:
# cat /usr/lib/libncurses.so
INPUT(-lncursesw)
I try to link -lncursesw directly, but there is still link error:
/usr/bin/ld: cannot find -lncursesw
collect2: error: ld returned 1 exit status
Why can't ld find libcurses.so even though it is in /usr/lib directory?
Update:
I am building bpftrace project, and the link error is as following:
[ 29%] Linking CXX executable bpftrace
cd /root/Project/bpftrace/build/src && /usr/bin/cmake -E cmake_link_script CMakeFiles/bpftrace.dir/link.txt --verbose=1
/usr/bin/c++ -g -static -rdynamic CMakeFiles/bpftrace.dir/ast.cpp.o CMakeFiles/bpftrace.dir/attached_probe.cpp.o CMakeFiles/bpftrace.dir/bpftrace.cpp.o CMakeFiles/bpftrace.dir/codegen_llvm.cpp.o CMakeFiles/bpftrace.dir/driver.cpp.o CMakeFiles/bpftrace.dir/irbuilderbpf.cpp.o CMakeFiles/bpftrace.dir/main.cpp.o CMakeFiles/bpftrace.dir/map.cpp.o CMakeFiles/bpftrace.dir/mapkey.cpp.o CMakeFiles/bpftrace.dir/printer.cpp.o CMakeFiles/bpftrace.dir/printf.cpp.o CMakeFiles/bpftrace.dir/semantic_analyser.cpp.o CMakeFiles/bpftrace.dir/types.cpp.o -o bpftrace arch/libarch.a ../libparser.a /usr/lib/libLLVMBPFCodeGen.a /usr/lib/libLLVMipo.a /usr/lib/libLLVMIRReader.a /usr/lib/libLLVMMCJIT.a ../bcc-prefix/src/bcc-build/src/cc/libbpf.a ../bcc-prefix/src/bcc-build/src/cc/libbcc-loader-static.a ../bcc-prefix/src/bcc-build/src/cc/libbcc.a -lelf /usr/lib/libLLVMAsmPrinter.a /usr/lib/libLLVMDebugInfoCodeView.a /usr/lib/libLLVMDebugInfoMSF.a /usr/lib/libLLVMBPFDesc.a /usr/lib/libLLVMBPFAsmPrinter.a /usr/lib/libLLVMBPFInfo.a /usr/lib/libLLVMSelectionDAG.a /usr/lib/libLLVMCodeGen.a /usr/lib/libLLVMAsmParser.a /usr/lib/libLLVMBitWriter.a /usr/lib/libLLVMInstrumentation.a /usr/lib/libLLVMLinker.a /usr/lib/libLLVMScalarOpts.a /usr/lib/libLLVMInstCombine.a /usr/lib/libLLVMVectorize.a /usr/lib/libLLVMTransformUtils.a /usr/lib/libLLVMExecutionEngine.a /usr/lib/libLLVMTarget.a /usr/lib/libLLVMAnalysis.a /usr/lib/libLLVMProfileData.a /usr/lib/libLLVMRuntimeDyld.a /usr/lib/libLLVMObject.a /usr/lib/libLLVMBitReader.a /usr/lib/libLLVMCore.a /usr/lib/libLLVMMCParser.a /usr/lib/libLLVMMC.a /usr/lib/libLLVMSupport.a -lrt -ldl -lcurses -lpthread -lz -lm /usr/lib/libLLVMDemangle.a
/usr/lib/libLLVMSupport.a(DynamicLibrary.cpp.o): In function `llvm::sys::DynamicLibrary::getPermanentLibrary(char const*, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >*)':
(.text._ZN4llvm3sys14DynamicLibrary19getPermanentLibraryEPKcPNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE+0x6e): warning: Using 'dlopen' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking
/usr/bin/ld: cannot find -lcurses
collect2: error: ld returned 1 exit status
I suppose your problem is here:
/usr/bin/c++ -g -static
you use -static, this mean:
On systems that support dynamic linking, this prevents linking with
the shared libraries. On other systems, this option has no effect.
So to successefull link you need libcurses**.a**, not .so
installing from source some software on Ubuntu, with some shell script, I end up with the following error..
vagrant#precise64:~/EventStore-oss-v3.5.0$ bash -x ./scripts/build-js1/build-js1-linux.sh werror=no
...
+ make x64.release werror=no
make[1]: Entering directory `/home/vagrant/EventStore-oss-v3.5.0/scripts/build-js1/v8/out'
make[1]: Nothing to be done for `all'.
make[1]: Leaving directory `/home/vagrant/EventStore-oss-v3.5.0/scripts/build-js1/v8/out'
+ popd
+ local outputDir=/home/vagrant/EventStore-oss-v3.5.0/scripts/build-js1/../../src/libs/x64/ubuntu-12.04
+ [[ -d /home/vagrant/EventStore-oss-v3.5.0/scripts/build-js1/../../src/libs/x64/ubuntu-12.04 ]]
+ pushd /home/vagrant/EventStore-oss-v3.5.0/scripts/build-js1/../../src/EventStore.Projections.v8Integration/
+ local outputObj=/home/vagrant/EventStore-oss-v3.5.0/scripts/build-js1/../../src/libs/x64/ubuntu-12.04/libjs1.so
+ g++ -I '/home/vagrant/EventStore-oss-v3.5.0/scripts/build-js1/v8/include *.cpp' -o /home/vagrant/EventStore-oss-v3.5.0/scripts/build-js1/../../src/libs/x64/ubuntu-12.04/libjs1.so -fPIC -shared -std=c++0x -lstdc++ -Wl,--start-group '/home/vagrant/EventStore-oss-v3.5.0/scripts/build-js1/v8/out/x64.release/obj.target/tools/gyp/libv8_{base.x64,nosnapshot.x64}.a' '/home/vagrant/EventStore-oss-v3.5.0/scripts/build-js1/v8/out/x64.release/obj.target/third_party/icu/libicu{i18n,uc,data}.a' -Wl,--end-group -lrt -lpthread
g++: error: /home/vagrant/EventStore-oss-v3.5.0/scripts/build-js1/v8/out/x64.release/obj.target/tools/gyp/libv8_{base.x64,nosnapshot.x64}.a: No such file or directory
g++: error: /home/vagrant/EventStore-oss-v3.5.0/scripts/build-js1/v8/out/x64.release/obj.target/third_party/icu/libicu{i18n,uc,data}.a: No such file or directory
vagrant#precise64:~/EventStore-oss-v3.5.0$
Although if I try to see if those files exists, they do :
vagrant#precise64:~/EventStore-oss-v3.5.0$ ls -la /home/vagrant/EventStore-oss-v3.5.0/scripts/build-js1/v8/out/x64.release/obj.target/tools/gyp/libv8_{base.x64,nosnapshot.x64}.a
-rw-rw-r-- 1 vagrant vagrant 1162178 Mar 1 13:24 /home/vagrant/EventStore-oss-v3.5.0/scripts/build-js1/v8/out/x64.release/obj.target/tools/gyp/libv8_base.x64.a
-rw-rw-r-- 1 vagrant vagrant 3580 Mar 1 13:25 /home/vagrant/EventStore-oss-v3.5.0/scripts/build-js1/v8/out/x64.release/obj.target/tools/gyp/libv8_nosnapshot.x64.a
and
vagrant#precise64:~/EventStore-oss-v3.5.0$ ls -la /home/vagrant/EventStore-oss-v3.5.0/scripts/build-js1/v8/out/x64.release/obj.target/third_party/icu/libicu{i18n,uc,data}.a
-rw-rw-r-- 1 vagrant vagrant 338 Mar 1 13:29 /home/vagrant/EventStore-oss-v3.5.0/scripts/build-js1/v8/out/x64.release/obj.target/third_party/icu/libicudata.a
-rw-rw-r-- 1 vagrant vagrant 314000 Mar 1 13:27 /home/vagrant/EventStore-oss-v3.5.0/scripts/build-js1/v8/out/x64.release/obj.target/third_party/icu/libicui18n.a
-rw-rw-r-- 1 vagrant vagrant 147746 Mar 1 13:29 /home/vagrant/EventStore-oss-v3.5.0/scripts/build-js1/v8/out/x64.release/obj.target/third_party/icu/libicuuc.a
Is there anything obvious linux principle I am missing ... ?
Could filename expansion be interpreted differently when used in a script and when used on the command line ?
When I try to do a manual source install of some software on NixOS 15.09, I get (sh -x is to get an exec log):
[nix-shell:/tmp/nix-shell-es/EventStore-oss-v3.5.0-src]$ sh -x scripts/build-js1/build-js1-linux.sh werror=no
...
+ CXXFLAGS=-fPIC
+ make x64.release werror=no
PYTHONPATH="/tmp/nix-shell-es/EventStore-oss-v3.5.0-src/scripts/build-js1/v8/tools/generate_shim_headers:" \
GYP_GENERATORS=make \
build/gyp/gyp --generator-output="out" build/all.gyp \
-Ibuild/standalone.gypi --depth=. \
-Dv8_target_arch=x64 \
-Dv8_optimized_debug=0 \
-S.x64.release -Dv8_enable_backtrace=1 -Dwerror='' -Darm_fpu=default -Darm_float_abi=default
/bin/sh: build/gyp/gyp: /bin/bash: bad interpreter: No such file or directory
Makefile:389: recipe for target 'out/Makefile.x64.release' failed
make: *** [out/Makefile.x64.release] Error 126
And indeed there is no bash program in /bin/
[nix-shell:/tmp/nix-shell-es/EventStore-oss-v3.5.0-src]$ ls -la /bin/
total 12
drwxr-xr-x 2 root root 4096 Feb 24 12:25 .
drwxr-xr-x 18 root root 4096 Feb 24 12:16 ..
lrwxrwxrwx 1 root root 63 Feb 24 12:25 sh -> /nix/store/l80ddf18bbig2icv6cmgjfws9a2vm3jj-bash-4.3-p42/bin/sh
However when I inspect the script I dont see any mention of it so it must be some subprogram looking for it.
As an aside, I imagine that's probably why the script wisely starts with #!/usr/bin/env bash and not the direct location of bash.
Anyone knows a blessed way to deal with this ?
one has to run patchShebangs ./scripts/build-js1/build-js1-linux.sh on files coming from source when they are not in the store and we want to execute them.