I'm compiling a c file in xv6 and I used their Makefile to compile. I used readelf and found out the ELF it outputs has just one program header.
ryan#ubuntu:~/Documents/xv6-OS-for-arm-v8-fixed/xv6-armv8/usr$ readelf -l _init --wide
Elf file type is EXEC (Executable file)
Entry point 0x0
There is 1 program header, starting at offset 64
Program Headers:
Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align
LOAD 0x000078 0x0000000000000000 0x0000000000000000 0x0011a8 0x0011c0 RWE 0x8
Section to Segment mapping:
Segment Sections...
00 .text .rodata .data .bss
This program header has just 4 sections: .text .rodata .data .bss
I checked its CFLAGS and it's showed below:
CROSSCOMPILE := aarch64-none-elf-
# try linux eabi
# CROSSCOMPILE := arm-linux-gnueabi-
CC = $(CROSSCOMPILE)gcc
AS = $(CROSSCOMPILE)as
LD = $(CROSSCOMPILE)ld
OBJCOPY = $(CROSSCOMPILE)objcopy
OBJDUMP = $(CROSSCOMPILE)objdump
CFLAGS = -march=armv8-a -mtune=cortex-a57 -fno-pic -static -fno-builtin -fno-strict-aliasing -Wall -I. -g
LDFLAGS = -L.
ASFLAGS = -march=armv8-a
But I don't know which of these flags make it this way.
I'm build a ARM-based OS. How can I compile one of this ELF in ARM by myself?
Today I met a really interesting problem with my NixOS distro. I just wanted to create a statically compiled OCaml progam and couldn`t do that. Then I tried to do that with an ANSI C canonical toy "hello world!" application:
$> cat mytest.c
#include <stdio.h>
int
main ()
{
puts ("hello world!") ;
}
My distro:
$> uname -a
Linux cat 4.19.36 #1-NixOS SMP Sat Apr 20 07:16:05 UTC 2019 x86_64 GNU/Linux
Compiler:
$> gcc -v
Using built-in specs.
COLLECT_GCC=/nix/store/myq0x6mjbdzxr9fckqn6kgy89kz19nkp-gfortran-7.4.0/bin/gcc
COLLECT_LTO_WRAPPER=/nix/store/myq0x6mjbdzxr9fckqn6kgy89kz19nkp-gfortran-7.4.0/libexec/gcc/x86_64-unknown-linux-gnu/7.4.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with:
Thread model: posix
gcc version 7.4.0 (GCC)
Cannot produce static exec :
$> gcc -static mytest.c -o hello
/nix/store/0y7jmqnj48ikjh37n3dl9kqw9hnn68nq-binutils-2.31.1/bin/ld: cannot find -lc
collect2: error: ld returned 1 exit status
Any ideas?
Usually a "dynamically linked" program hello is generated by gccwithout a problem.
No such issues on Lubuntu. I was advised to try a different distro and test that exec is running on NixOS. I did it - produced an exec with gcc on Lubuntu and started it on NixOS. Therefore I think that the problem is not with gcc but with NixOS.
How does NixOS treat this problem (i.e., generation of statically compiled exec files)?
And, of course, I'm also interested in the results concerning ocamlopt compiler rather then gcc but I think that the problem is common for all compilers (I tried Haskell ghc too by the way with the same results).
brgs
UPDATE: from a discussion on another thread:
1 #Ston17 You may have the .so but not the .a – norok2
2
3 yes - i have .so what the difference? can the presence of .a improve the situation? – Ston17
4
5 Yes. You typically need .a library to have the static linking work correctly – norok2
$> find /nix/store/ -name *libc.a.*
$>
can this be the reason?
UPDATE2: as concerning ocamlopt:
source file
$> cat mytest.ml
print_string "hello world!" ;;
print_newline () ;;
as you can see no special calls to anything. let try to make static exec:
$> ocamlopt -ccopt -static mytest.ml -o ocaml_test
/nix/store/0y7jmqnj48ikjh37n3dl9kqw9hnn68nq-binutils-2.31.1/bin/ld: cannot find -lm
/nix/store/0y7jmqnj48ikjh37n3dl9kqw9hnn68nq-binutils-2.31.1/bin/ld: cannot find -ldl
/nix/store/0y7jmqnj48ikjh37n3dl9kqw9hnn68nq-binutils-2.31.1/bin/ld: cannot find -lc
collect2: error: ld returned 1 exit status
so ld just cannot link to static version of libc. and i cannot find libc.a in the hole system
any suggetions?
here https://vaibhavsagar.com/blog/2018/01/03/static-haskell-nix/ is explained how you could obtain in NixOS statical versions of sys libraries
nix-shell config file:
let
pkgs = import <nixpkgs> {} ;
in pkgs.buildFHSUserEnv {
name = "fhs" ;
targetPkgs = pkgs: with pkgs; [
pkgs.glibc.static
pkgs.zlib.static
pkgs.libffi
pkgs.libtool
pkgs.musl
pkgs.ghc
pkgs.gcc
pkgs.ocaml
] ;
}
after that in nix-shell you start chroot FHS and copy needed sys libs into your folder and close chroot FHS
and after that compile your file staticaly
good with gcc:
$> gcc -static -L/home/.local/lib/ mytest.c -o ansiC_test
$> ldd ansiC_test
not a dynamic executable
not so good but maybe working with ocaml:
ocamlopt -ccopt -static -cclib -L/home/.local/lib mytest.ml -o ocaml_test
ocamlopt -ccopt -static -cclib -L/home/nomad/.local/lib mytest.ml -o ocaml_test
/nix/store/0y7jmqnj48ikjh37n3dl9kqw9hnn68nq-binutils-2.31.1/bin/ld: /nix/store/j1v6kkxq081q4m4fw7gazaf6rb3vy87p-ocaml-4.06.1/lib/ocaml/libasmrun.a(unix.o): in function `caml_dlopen':
/build/ocaml-4.06.1/asmrun/unix.c:273: warning: Using 'dlopen' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking
$> ldd ocaml_test
not a dynamic executable
dont work with ghc though :
ghc -static -optl-static -L/home/.local/lib/ mytest.hs -o haskell_test
[1 of 1] Compiling Main ( mytest.hs, mytest.o )
Linking haskell_test ...
/nix/store/0y7jmqnj48ikjh37n3dl9kqw9hnn68nq-binutils-2.31.1/bin/ld: /nix/store/wfgrz42bpcl1r635dasfk7r236hm83az-ghc-8.6.4/lib/ghc-8.6.4/rts/libHSrts.a(Linker.o): in function `internal_dlopen':
Linker.c:(.text.internal_dlopen+0x7): warning: Using 'dlopen' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking
/nix/store/0y7jmqnj48ikjh37n3dl9kqw9hnn68nq-binutils-2.31.1/bin/ld: cannot find -lffi
collect2: error: ld returned 1 exit status
`cc' failed in phase `Linker'. (Exit code: 1)
make: *** [makefile:5: haskell] Error 1
ok. ocaml works:
lubuntu#lubuntu:~/Documents$ ./ocaml_hello_nix
hello world!
lubuntu#lubuntu:~/Documents$ readelf -l ocaml_hello_nix
Elf file type is EXEC (Executable file)
Entry point 0x4017a0
There are 9 program headers, starting at offset 64
Program Headers:
Type Offset VirtAddr PhysAddr
FileSiz MemSiz Flags Align
LOAD 0x0000000000000000 0x0000000000400000 0x0000000000400000
0x00000000000005d8 0x00000000000005d8 R 0x1000
LOAD 0x0000000000001000 0x0000000000401000 0x0000000000401000
0x0000000000107275 0x0000000000107275 R E 0x1000
LOAD 0x0000000000109000 0x0000000000509000 0x0000000000509000
0x00000000000db191 0x00000000000db191 R 0x1000
LOAD 0x00000000001e5140 0x00000000005e6140 0x00000000005e6140
0x0000000000008a18 0x000000000001dfe0 RW 0x1000
NOTE 0x0000000000000238 0x0000000000400238 0x0000000000400238
0x0000000000000020 0x0000000000000020 R 0x4
NOTE 0x0000000000000258 0x0000000000400258 0x0000000000400258
0x0000000000000020 0x0000000000000020 R 0x8
TLS 0x00000000001e5140 0x00000000005e6140 0x00000000005e6140
0x0000000000000020 0x0000000000000060 R 0x8
GNU_STACK 0x0000000000000000 0x0000000000000000 0x0000000000000000
0x0000000000000000 0x0000000000000000 RW 0x10
GNU_RELRO 0x00000000001e5140 0x00000000005e6140 0x00000000005e6140
0x0000000000002ec0 0x0000000000002ec0 R 0x1
Section to Segment mapping:
Segment Sections...
00 .note.ABI-tag .note.gnu.property .rela.plt
01 .init .plt .text __libc_freeres_fn __libc_thread_freeres_fn .fini
02 .rodata .eh_frame .gcc_except_table
03 .tdata .init_array .fini_array .data.rel.ro .got .got.plt .data __libc_subfreeres __libc_IO_vtables __libc_atexit __libc_thread_subfreeres .bss __libc_freeres_ptrs
04 .note.ABI-tag
05 .note.gnu.property
06 .tdata .tbss
07
08 .tdata .init_array .fini_array .data.rel.ro .got
haskell works. the reason was that binary NixOS packet was built without FFI support. i installed ghc from sources and all become fine:
lubuntu#lubuntu:~/Documents$ ./haskell_hello_nix
hello world!
lubuntu#lubuntu:~/Documents$ readelf -l haskell_hello_nix
Elf file type is EXEC (Executable file)
Entry point 0x405d40
There are 6 program headers, starting at offset 64
Program Headers:
Type Offset VirtAddr PhysAddr
FileSiz MemSiz Flags Align
LOAD 0x0000000000000000 0x0000000000400000 0x0000000000400000
0x0000000000188ba4 0x0000000000188ba4 R E 0x1000
LOAD 0x0000000000188ec0 0x0000000000589ec0 0x0000000000589ec0
0x00000000000104c0 0x000000000001ac98 RW 0x1000
NOTE 0x0000000000000190 0x0000000000400190 0x0000000000400190
0x0000000000000020 0x0000000000000020 R 0x4
GNU_STACK 0x0000000000000000 0x0000000000000000 0x0000000000000000
0x0000000000000000 0x0000000000000000 RW 0x10
TLS 0x0000000000188ec0 0x0000000000589ec0 0x0000000000589ec0
0x0000000000000070 0x00000000000000b8 R 0x8
GNU_RELRO 0x0000000000188ec0 0x0000000000589ec0 0x0000000000589ec0
0x0000000000003140 0x0000000000003140 RW 0x20
Section to Segment mapping:
Segment Sections...
00 .note.ABI-tag .rela.plt .init .plt .text __libc_thread_freeres_fn .fini .rodata .gcc_except_table .eh_frame
01 .tdata .data.rel.ro.local .fini_array .init_array .data.rel.ro .preinit_array .got .got.plt .data .tm_clone_table __libc_IO_vtables __libc_atexit __libc_thread_subfreeres .bss __libc_freeres_ptrs
02 .note.ABI-tag
03
04 .tdata .tbss
05 .tdata .data.rel.ro.local .fini_array .init_array .data.rel.ro .preinit_array .got
good. tnx to all who was concerned. you save my a$$
g++ (GCC) 5.2.0
clang version 3.7.1 (tags/RELEASE_371/final)
GNU gdb (GDB) 7.12
Gdb is unable to locate the definition of std::string when compiled with clang for some reason. I have custom compiled and build gcc and clang as Centos 6.5 comes with older version of gcc.
Example code
#include <string>
int main()
{
std::string s("This is a string");
return 0;
}
Compile with g++ and debug - works just fine
[~]$ g++ -ggdb3 -std=c++14 stl.cpp
[~]$ gdb a.out
GNU gdb (GDB) 7.12
Reading symbols from a.out...done.
(gdb) break main
Breakpoint 1 at 0x400841: file stl.cpp, line 5.
(gdb) r
Starting program: /home/vagrant/a.out
Breakpoint 1, main () at stl.cpp:5
5 std::string s("This is a string");
(gdb) n
7 return 0;
(gdb) p s
$1 = {static npos = <optimized out>,
_M_dataplus = {<std::allocator<char>> = {<__gnu_cxx::new_allocator<char>> = {<No data fields>}, <No data fields>}, _M_p = 0x612c20 "This is a string"}, _M_string_length = 16, {
_M_local_buf = "\020\000\000\000\000\000\000\000\300\b#\000\000\000\000", _M_allocated_capacity = 16}}
(gdb)
Check that it is linking with my rpm build version of libstdc++ and not system
[~]$ ldd a.out
linux-vdso.so.1 => (0x00007ffd709e0000)
libstdc++.so.6 => /opt/spotx-gcc/lib64/libstdc++.so.6 (0x00007f29318fa000)
libm.so.6 => /lib64/libm.so.6 (0x00007f2931676000)
libgcc_s.so.1 => /opt/spotx-gcc/lib64/libgcc_s.so.1 (0x00007f293145f000)
libc.so.6 => /lib64/libc.so.6 (0x00007f29310cb000)
/lib64/ld-linux-x86-64.so.2 (0x00007f2931c93000)
[~]$ objdump -T -C a.out
a.out: file format elf64-x86-64
DYNAMIC SYMBOL TABLE:
0000000000000000 w D *UND* 0000000000000000 __gmon_start__
0000000000000000 w D *UND* 0000000000000000 _Jv_RegisterClasses
0000000000000000 DF *UND* 0000000000000000 GLIBC_2.2.5 __libc_start_main
0000000000000000 w D *UND* 0000000000000000 _ITM_deregisterTMCloneTable
0000000000000000 w D *UND* 0000000000000000 _ITM_registerTMCloneTable
0000000000000000 DF *UND* 0000000000000000 GLIBCXX_3.4.21 std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::~basic_string()
0000000000000000 DF *UND* 0000000000000000 GLIBCXX_3.4 std::allocator<char>::~allocator()
0000000000000000 DF *UND* 0000000000000000 GLIBCXX_3.4.21 std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::basic_string(char const*, std::allocator<char> const&)
0000000000000000 DF *UND* 0000000000000000 GLIBCXX_3.4 std::allocator<char>::allocator()
0000000000000000 DF *UND* 0000000000000000 GCC_3.0 _Unwind_Resume
0000000000400700 DF *UND* 0000000000000000 CXXABI_1.3 __gxx_personality_v0
All looks good now if I try the same with clang
[~]$ clang++ -std=c++14 -g stl.cpp
[~]$ gdb a.out
GNU gdb (GDB) 7.12
Reading symbols from a.out...done.
(gdb) break main
Breakpoint 1 at 0x400853: file stl.cpp, line 5.
(gdb) r
Starting program: /home/vagrant/a.out
Breakpoint 1, main () at stl.cpp:5
5 std::string s("This is a string");
(gdb) n
7 return 0;
(gdb) p s
$1 = <incomplete type>
(gdb)
Now I get an incomplete type - but the same libraries are being used
[~]$ ldd a.out
linux-vdso.so.1 => (0x00007fff5352d000)
libstdc++.so.6 => /opt/spotx-gcc/lib64/libstdc++.so.6 (0x00007f76b4023000)
libm.so.6 => /lib64/libm.so.6 (0x00007f76b3d9f000)
libgcc_s.so.1 => /opt/spotx-gcc/lib64/libgcc_s.so.1 (0x00007f76b3b88000)
libc.so.6 => /lib64/libc.so.6 (0x00007f76b37f4000)
/lib64/ld-linux-x86-64.so.2 (0x00007f76b43bc000)
[~]$ objdump -T -C a.out
a.out: file format elf64-x86-64
DYNAMIC SYMBOL TABLE:
0000000000000000 w D *UND* 0000000000000000 __gmon_start__
0000000000000000 w D *UND* 0000000000000000 _Jv_RegisterClasses
0000000000000000 DF *UND* 0000000000000000 GLIBC_2.2.5 __libc_start_main
0000000000000000 w D *UND* 0000000000000000 _ITM_deregisterTMCloneTable
0000000000000000 w D *UND* 0000000000000000 _ITM_registerTMCloneTable
0000000000000000 DF *UND* 0000000000000000 GLIBCXX_3.4.21 std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::~basic_string()
0000000000000000 DF *UND* 0000000000000000 GLIBCXX_3.4 std::allocator<char>::~allocator()
0000000000000000 DF *UND* 0000000000000000 GLIBCXX_3.4.21 std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::basic_string(char const*, std::allocator<char> const&)
0000000000000000 DF *UND* 0000000000000000 GLIBCXX_3.4 std::allocator<char>::allocator()
0000000000000000 DF *UND* 0000000000000000 GCC_3.0 _Unwind_Resume
0000000000400700 DF *UND* 0000000000000000 CXXABI_1.3 __gxx_personality_v0
Does anyone have any advice on where to look or something that I've missed. Both compilers are bootstrapped when building them - everything seems fine - it just appears to be std::string is not defined when using clang.
As ks1322 mentioned, this is because clang has decided not to emit debug information for libstc++.
You can force clang to do so by providing the following flag:
-D_GLIBCXX_DEBUG
I would only provide the flag for debug builds, but if debug is the default and release builds are a special target you should remove it:
release: CXXFLAGS := $(filter-out -D_GLIBCXX_DEBUG,$(CXXFLAGS)) -O2
This has fixed the same problem for me.
The last workaround mentioned in bug 24202 as linked by ks1322 is worth having a look at:
-fno-limit-debug-info will make your debug info larger, slow link (if you're not using -gsplit-dwarf) and debugger performance. But, yes, will address this.
Using -fno-limit-debug-info forces Clang to emit debug information for e.g. std::string at the cost of a larger binary while preserving compatibility with other libraries and the rest of the system/SDK.
As ks1322 and Kevin mentioned, one can instead use -D_GLIBCXX_DEBUG to switch libstdc++ into debug mode but this comes at a heavy price: any library you link against and with which you exchange STL containers (string, vector, etc.) must also be built with -D_GLIBCXX_DEBUG. Meaning: your system/SDK must either support this with a separate set of libraries or you will have to rebuild them yourself.
I've reproduced this issue on Fedora with system clang.
It appears that clang is not emitting debug information for std::string because it was told that libstdc++ provides it. See this comment from bug 24202:
Looks like you don't have debug information for libstdc++ installed:
Missing separate debuginfos, use: dnf debuginfo-install libgcc-5.1.1-4.fc22.x86_64 libstdc++-5.1.1-4.fc22.x86_64
Clang is not emitting debug information for std::string because it was
told that libstdc++ provides it (but in your case, it's not
installed); this is a debug size optimization that GCC apparently
doesn't perform.
Does this work if you install the debug information for libstdc++?
I've installed debug info for libstdc++ with command dnf debuginfo-install libstdc++-6.2.1-2.fc25.x86_64 and that resolved the issue.
clang trusts that debugging symbols for libstd++ are available, so you have to install them. See ks1322's answer for how to do that on Fedora. On Ubuntu, run:
sudo apt-get install libstdc++6-dbgsym
After that, things will just work.
Do not define _GLIBCXX_DEBUG since that'll break libstdc++'s abi.
-fno-limit-debug-info will make clang emit debug info that's larger than necessary, so I'd advise against that too. Just install the debug info package for libstdc++.
for me:
-fno-limit-debug-info is the real solution for clang / clion.
_GLIBCXX_DEBUG cause link error with some library
clang version 10.0.0-4ubuntu1
Target: x86_64-pc-linux-gnu
Thread model: posix
InstalledDir: /usr/bin
CLion 2022.1.3
Build #CL-221.5921.27, built on June 21, 2022
I am using yocto jethro to build my bespoke linux distro for a OMAP3630 processor. I have a precompiled linaro toolchain version gcc-4.7.3 and my kernel is version 3.2. I am trying to upgrade my cross compiler to gcc-4.8.4 (using the gcc version provided by yocto, not linaro).
Everything seems to compile correctly, but when I run the kernel, I get the following alignment exception error message:
[ 0.516387] Unhandled fault: alignment exception (0x001) at 0x0073656b
[ 0.523193] Internal error: : 1 [#1] PREEMPT
[ 0.527679] Modules linked in:
[ 0.530914] CPU: 0 Tainted: G W (3.2.0-rc1 #6)
[ 0.536834] PC is at rb_next+0x24/0x68
[ 0.540771] LR is at sysfs_remove_dir+0x84/0xcc
[ 0.545532] pc : [<c0194948>] lr : [<c0130084>] psr: 20000013
[ 0.545532] sp : cf837f70 ip : 22222222 fp : 00000000
[ 0.557525] r10: 00000000 r9 : c04c95e0 r8 : 00000000
[ 0.562988] r7 : c04c9724 r6 : cf837f40 r5 : fffffffe r4 : cf801cc0
[ 0.569793] r3 : 69766564 r2 : 00736563 r1 : 22222222 r0 : cf801cc0
[ 0.576629] Flags: nzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment kernel
[ 0.584228] Control: 10c5387f Table: 80004019 DAC: 00000015
[ 0.590240] Process swapper (pid: 1, stack limit = 0xcf8362f0)
[ 0.596313] Stack: (0xcf837f70 to 0xcf838000)
[ 0.600891] 7f60: cf812310 00000000 c04c95e8 fffffffe
[ 0.609405] 7f80: 00000000 c01900a4 c04c95e8 c01d7ae4 00000000 00000000 c04c95e0 ffff6a0e
[ 0.617919] 7fa0: 00000000 c01e40b8 00000000 c0497aa4 00007fb0 c000f1b8 00000013 00000000
[ 0.626434] 7fc0: 00000000 00000000 00000000 c0475784 c0497aa4 c0475818 cf80f8c0 c045d80c
[ 0.634948] 7fe0: 00000000 00000000 00000000 00000000 c045d78c c000f1b8 2b22d90f 18552020
[ 0.643463] [<c0194948>] (rb_next+0x24/0x68) from [<c0130084>] (sysfs_remove_dir+0x84/0xcc)
[ 0.652160] [<c0130084>] (sysfs_remove_dir+0x84/0xcc) from [<c01900a4>] (kobject_del+0x10/0x38)
[ 0.661224] [<c01900a4>] (kobject_del+0x10/0x38) from [<c01d7ae4>] (device_add+0x12c/0x59c)
[ 0.669921] [<c01d7ae4>] (device_add+0x12c/0x59c) from [<c0475784>] (platform_bus_init+0x14/0x4c)
[ 0.679168] [<c0475784>] (platform_bus_init+0x14/0x4c) from [<c0475818>] (driver_init+0x1c/0x28)
[ 0.688293] [<c0475818>] (driver_init+0x1c/0x28) from [<c045d80c>] (kernel_init+0x80/0x120)
[ 0.696990] [<c045d80c>] (kernel_init+0x80/0x120) from [<c000f1b8>] (kernel_thread_exit+0x0/0x8)
[ 0.706146] Code: e3520000 1a000001 ea000005 e1a02003 (e5923008)
[ 0.712524] ---[ end trace 1b75b31a2719ed22 ]---
[ 0.717407] Kernel panic - not syncing: Attempted to kill init!
I had a similar issue before with gcc-4.7.3, that I solved adding -mno-unaligned-access to EXTRA_CFLAGS when compiling the kernel, but it doesn't seem to fix the problem with gcc-4.8.4. I have also compared gcc commands when compiling the kernel with one version and the other and they are identical. I have briefly tested gcc-4.9 as well with similar results. This makes me think that yocto gcc could be configured incorrectly, but no idea of what specific config value could be causing this.
Some info about my gcc-4.7.3:
$ arm-none-linux-gnueabi-gcc -v
Using built-in specs.
COLLECT_GCC=/home/alima/projects/yocto/build/../poky/external-precompiled-toolchain/toolchains/arm-linaro-5//bin/arm-none-linux-gnueabi-gcc
COLLECT_LTO_WRAPPER=/home/alima/projects/yocto/poky/external-precompiled-toolchain/toolchains/Thumb2_linaro-4.7-2012.11_eglibc-2.16/bin/../libexec/gcc/arm-none-linux-gnueabi/4.7.3/lto-wrapper
Target: arm-none-linux-gnueabi
Configured with: /tmp/build/src/gcc-linaro-4.7-2012.11/configure --build=x86_64-build_unknown-linux-gnu --host=x86_64-build_unknown-linux-gnu --target=arm-none-linux-gnueabi --prefix=/opt/toolchains/arm-linaro-5 --with-sysroot=/opt/toolchains/arm-linaro-5/arm-none-linux-gnueabi/sysroot --enable-languages=c,c++ --with-arch=armv7-a --with-fpu=neon --with-float=hard --with-pkgversion='crosstool-NG hg+default-2af20cfd210b - arm-linaro-4' --enable-__cxa_atexit --disable-libmudflap --disable-libgomp --disable-libssp --disable-libquadmath --disable-libquadmath-support --with-gmp=/tmp/build/arm-none-linux-gnueabi/buildtools --with-mpfr=/tmp/build/arm-none-linux-gnueabi/buildtools --with-mpc=/tmp/build/arm-none-linux-gnueabi/buildtools --with-ppl=/tmp/build/arm-none-linux-gnueabi/buildtools --with-cloog=/tmp/build/arm-none-linux-gnueabi/buildtools --with-libelf=/tmp/build/arm-none-linux-gnueabi/buildtools --with-host-libstdcxx='-static-libgcc -Wl,-Bstatic,-lstdc++,-Bdynamic -lm -L/tmp/build/arm-none-linux-gnueabi/buildtools/lib -lpwl' --enable-threads=posix --enable-target-optspace --disable-nls --disable-multilib --with-local-prefix=/opt/toolchains/arm-linaro-5/arm-none-linux-gnueabi/sysroot --enable-c99 --enable-long-long --with-mode=thumb --with-float=hard --disable-clocale
Thread model: posix
gcc version 4.7.3 20121106 (prerelease) (crosstool-NG hg+default-2af20cfd210b - arm-linaro-4)
And the same for gcc-4.8.4:
$ arm-none-linux-gnueabi-gcc -v
Using built-in specs.
COLLECT_GCC=/home/alima/projects/yocto/build/tmp-tiny/sysroots/x86_64-linux/usr/bin/arm-none-linux-gnueabi/arm-none-linux-gnueabi-gcc
COLLECT_LTO_WRAPPER=/home/alima/projects/yocto/build/tmp-tiny/sysroots/x86_64-linux/usr/libexec/arm-none-linux-gnueabi/gcc/arm-none-linux-gnueabi/4.8.4/lto-wrapper
Target: arm-none-linux-gnueabi
Configured with: /home/alima/projects/yocto/build/tmp-tiny/work-shared/gcc-4.8.4-r0/gcc-4.8.4/configure --build=x86_64-linux --host=x86_64-linux --target=arm-none-linux-gnueabi --prefix=/home/alima/projects/yocto/build/tmp-tiny/sysroots/x86_64-linux/usr --exec_prefix=/home/alima/projects/yocto/build/tmp-tiny/sysroots/x86_64-linux/usr --bindir=/home/alima/projects/yocto/build/tmp-tiny/sysroots/x86_64-linux/usr/bin/arm-none-linux-gnueabi --sbindir=/home/alima/projects/yocto/build/tmp-tiny/sysroots/x86_64-linux/usr/bin/arm-none-linux-gnueabi --libexecdir=/home/alima/projects/yocto/build/tmp-tiny/sysroots/x86_64-linux/usr/libexec/arm-none-linux-gnueabi --datadir=/home/alima/projects/yocto/build/tmp-tiny/sysroots/x86_64-linux/usr/share --sysconfdir=/home/alima/projects/yocto/build/tmp-tiny/sysroots/x86_64-linux/etc --sharedstatedir=/home/alima/projects/yocto/build/tmp-tiny/sysroots/x86_64-linux/com --localstatedir=/home/alima/projects/yocto/build/tmp-tiny/sysroots/x86_64-linux/var --libdir=/home/alima/projects/yocto/build/tmp-tiny/sysroots/x86_64-linux/usr/lib/arm-none-linux-gnueabi --includedir=/home/alima/projects/yocto/build/tmp-tiny/sysroots/x86_64-linux/usr/include --oldincludedir=/home/alima/projects/yocto/build/tmp-tiny/sysroots/x86_64-linux/usr/include --infodir=/home/alima/projects/yocto/build/tmp-tiny/sysroots/x86_64-linux/usr/share/info --mandir=/home/alima/projects/yocto/build/tmp-tiny/sysroots/x86_64-linux/usr/share/man --disable-silent-rules --disable-dependency-tracking --with-libtool-sysroot=/home/alima/projects/yocto/build/tmp-tiny/sysroots/x86_64-linux --enable-clocale=generic --with-gnu-ld --enable-shared --enable-languages=c,c++ --enable-threads=posix --disable-multilib --enable-c99 --enable-long-long --enable-symvers=gnu --enable-libstdcxx-pch --program-prefix=arm-none-linux-gnueabi- --without-local-prefix --enable-target-optspace --enable-lto --enable-libssp --disable-bootstrap --disable-libmudflap --with-system-zlib --with-linker-hash-style=gnu --enable-linker-build-id --with-ppl=no --with-cloog=no --enable-checking=release --enable-cheaders=c_global --with-gxx-include-dir=/not/exist/usr/include/c++/4.8.4 --with-sysroot=/not/exist --with-build-sysroot=/home/alima/projects/yocto/build/tmp-tiny/sysroots/board --enable-poison-system-directories --with-mpfr=/home/alima/projects/yocto/build/tmp-tiny/sysroots/x86_64-linux/usr --with-system-zlib --disable-nls --with-arch=armv7-a
Thread model: posix
gcc version 4.8.4 (GCC)
My questions are: Does anyone know what could be causing this? Even if you are not sure, could you please comment so I can check it?
Thank you all in advance.
I am trying to track down a larger problem and here is the simplified test case.
#include <netdb.h>
int main(int argc, char** argv)
{
getnetbyname("localhost");
return 0;
}
I compile as:
$ gcc -c -Werror -Wall foo.c
$ gcc foo.o
foo.o:foo.c:(.text+0x16): undefined reference to `getnetbyname'
collect2: error: ld returned 1 exit status
$ gcc foo.o -llwres
foo.o:foo.c:(.text+0x16): undefined reference to `getnetbyname'
collect2: error: ld returned 1 exit status
$ gcc foo.o -lwsock32
foo.o:foo.c:(.text+0x16): undefined reference to `getnetbyname'
collect2: error: ld returned 1 exit status
$ gcc foo.o -lmswsock
foo.o:foo.c:(.text+0x16): undefined reference to `getnetbyname'
collect2: error: ld returned 1 exit status
$ gcc foo.o -lamIcrazy
/usr/lib/gcc/i686-pc-cygwin/4.8.3/../../../../i686-pc-cygwin/bin/ld: cannot find -lamIcrazy
collect2: error: ld returned 1 exit status
Not sure where to go from here, I am pretty sure Perl uses this reference but I cannot follow the build (yet). gcc foo.o works on Centos 6.
Here are the .a files with the getnetbyname symbol
Binary file /usr/lib/perl5/5.14/i686-cygwin-threads-64int/CORE/libperl.a matches
Binary file /usr/lib/w32api/libmswsock.a matches
Binary file /usr/lib/w32api/libwsock32.a matches
$ nm /usr/lib/w32api/libmswsock.a --demangle | grep -B 10 getnetbyname
dqsls00019.o:
00000000 b .bss
00000000 d .data
00000000 i .idata$4
00000000 i .idata$5
00000000 i .idata$6
00000000 i .idata$7
00000000 t .text
U _head_lib32_libmswsock_a
00000000 I _imp__getnetbyname#4
00000000 T getnetbyname#4
$ nm /usr/lib/w32api/libwsock32.a --demangle | grep -B 10 getnetbyname
duegs00043.o:
00000000 b .bss
00000000 d .data
00000000 i .idata$4
00000000 i .idata$5
00000000 i .idata$6
00000000 i .idata$7
00000000 t .text
U _head_lib32_libwsock32_a
00000000 I _imp__getnetbyname#4
00000000 T getnetbyname#4
It looks like it is not implemented, per https://cygwin.com/cygwin-api/std-notimpl.html .
I must have misunderstood the exports from libwsock32.a and libmswsock.a