file(1) reports crazy file type that breaks ports lib dependency mechanism

V

Vincent Habchi

Folks,
I've been stuck for a while in this.

Had more time today to dig into it, using debug options in make and bash.

Turns out file(1) outputs a zany type for some .so files:

Code: 
Server > file -b -L --mime-type /usr/local/lib/libnghttp2.so
application/x-pie-executable
Server > file -b -L --mime-type /usr/local/lib/libzip.so
application/x-pie-executable
but:
Code: 
Server > file -b -L --mime-type /lib/libm.so.5
application/x-sharedlib

Any idea what cause could this?
Also:
Code: 
Server > uname -a
FreeBSD server 11.2-STABLE FreeBSD 11.2-STABLE #7 r338692: Sat Sep 15 15:40:30 CEST 2018     root@server:/usr/obj/usr/src/sys/MYKERNEL  amd64

Naturally, this breaks /usr/ports/Mk/Scripts/find-lib.sh which expects an x-sharedlib mime type and not what file(1) blurts.

Thanks!
 
I suspect your /usr/share/misc/magic got corrupted at some point:
Code: 
dice@armitage:~ % file -b -L --mime-type /usr/local/lib/libnghttp2.so
application/x-sharedlib
 
SirDice said:
I suspect your /usr/share/misc/magic got corrupted at some point:
Code: 
dice@armitage:~ % file -b -L --mime-type /usr/local/lib/libnghttp2.so
application/x-sharedlib
Click to expand...
Yeah, most probable answer, but when I search in /usr/share/misc/magic I can’t even find any “pie ” string, so I wonder where that “pie” comes from.
Code: 
file /usr/local/lib/libzip.so.5.0
/usr/local/lib/libzip.so.5.0: ELF 64-bit LSB pie executable

Err… On second thought, that doesn’t explain why /lib/libm.so.5 is correctly tagged.
 
Could you post your rmd160? Thanks!
Code: 
Server > rmd160 /usr/share/misc/magic
RMD160 (/usr/share/misc/magic) = 6e457f20d7c7601fbe2b2abb5418d5f1181a294c
 
Code: 
dice@armitage:~ % rmd160 /usr/share/misc/magic
RMD160 (/usr/share/misc/magic) = 6e457f20d7c7601fbe2b2abb5418d5f1181a294c
dice@armitage:~ % freebsd-version
11.2-RELEASE-p3
Hashes appear to be the same, so their contents would be too.

Might be useful:
Code: 
dice@armitage:~ % hexdump -C /usr/local/lib/libnghttp2.so | head
00000000  7f 45 4c 46 02 01 01 09  00 00 00 00 00 00 00 00  |.ELF............|
00000010  03 00 3e 00 01 00 00 00  90 50 00 00 00 00 00 00  |..>......P......|
00000020  40 00 00 00 00 00 00 00  40 84 02 00 00 00 00 00  |@.......@.......|
00000030  00 00 00 00 40 00 38 00  05 00 40 00 1a 00 19 00  |....@.8...@.....|
00000040  01 00 00 00 05 00 00 00  00 00 00 00 00 00 00 00  |................|
00000050  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000060  24 60 02 00 00 00 00 00  24 60 02 00 00 00 00 00  |$`......$`......|
00000070  00 00 20 00 00 00 00 00  01 00 00 00 06 00 00 00  |.. .............|
00000080  28 60 02 00 00 00 00 00  28 60 22 00 00 00 00 00  |(`......(`".....|
00000090  28 60 22 00 00 00 00 00  58 22 00 00 00 00 00 00  |(`".....X"......|
 
I copied the file to my MacBook Air and tried MacOS's file(1), same result:
Code: 
Air > file -b libnghttp2.so
ELF 64-bit LSB pie executable x86-64, version 1 (FreeBSD), dynamically linked, stripped

Air > hexdump -C libnghttp2.so | head

00000000  7f 45 4c 46 02 01 01 09  00 00 00 00 00 00 00 00  |.ELF............|
00000010  03 00 3e 00 01 00 00 00  90 50 00 00 00 00 00 00  |..>......P......|
00000020  40 00 00 00 00 00 00 00  90 84 02 00 00 00 00 00  |@...............|
00000030  00 00 00 00 40 00 38 00  05 00 40 00 1a 00 19 00  |....@.8...@.....|
00000040  01 00 00 00 05 00 00 00  00 00 00 00 00 00 00 00  |................|
00000050  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000060  24 60 02 00 00 00 00 00  24 60 02 00 00 00 00 00  |$`......$`......|
00000070  00 00 20 00 00 00 00 00  01 00 00 00 06 00 00 00  |.. .............|
00000080  28 60 02 00 00 00 00 00  28 60 22 00 00 00 00 00  |(`......(`".....|
00000090  28 60 22 00 00 00 00 00  58 22 00 00 00 00 00 00  |(`".....X"......|
So there appears to be a small difference in the 20 line, you have 40 84 02, I have 90 84 02. So file(1) is correct. Something is wrong with the header of my librairies. But what could’ve caused this?
 
Darn :(

Code: 
Server > cd */libnghttp2
Server > sudo make build
===>  License MIT accepted by the user
===>   libnghttp2-1.33.0 depends on file: /usr/local/sbin/pkg - found
===> Fetching all distfiles required by libnghttp2-1.33.0 for building
===>  Extracting for libnghttp2-1.33.0
=> SHA256 Checksum OK for nghttp2-nghttp2-v1.33.0_GH0.tar.gz.
===>  Patching for libnghttp2-1.33.0
===>  Applying FreeBSD patches for libnghttp2-1.33.0
===>   libnghttp2-1.33.0 depends on package: autoconf>=2.69 - found
===>   libnghttp2-1.33.0 depends on package: automake>=1.16.1 - found
===>   libnghttp2-1.33.0 depends on executable: libtoolize - found
===>   libnghttp2-1.33.0 depends on package: pkgconf>=1.3.0_1 - found
===>  Configuring for libnghttp2-1.33.0
/usr/local/share/aclocal/progsreiserfs.m4:13: warning: underquoted definition of AC_CHECK_LIBREISERFS
/usr/local/share/aclocal/progsreiserfs.m4:13:   run info Automake 'Extending aclocal'
[…]
libtool: link: (cd ".libs" && rm -f "libnghttp2.so.14" && ln -s "libnghttp2.so.14.17.0" "libnghttp2.so.14")
libtool: link: (cd ".libs" && rm -f "libnghttp2.so" && ln -s "libnghttp2.so.14.17.0" "libnghttp2.so")
libtool: link: ar cru .libs/libnghttp2.a  nghttp2_pq.o nghttp2_map.o nghttp2_queue.o nghttp2_frame.o nghttp2_buf.o nghttp2_stream.o nghttp2_outbound_item.o nghttp2_session.o nghttp2_submit.o nghttp2_helper.o nghttp2_npn.o nghttp2_hd.o nghttp2_hd_huffman.o nghttp2_hd_huffman_data.o nghttp2_version.o nghttp2_priority_spec.o nghttp2_option.o nghttp2_callbacks.o nghttp2_mem.o nghttp2_http.o nghttp2_rcbuf.o nghttp2_debug.o
libtool: link: ranlib .libs/libnghttp2.a
libtool: link: ( cd ".libs" && rm -f "libnghttp2.la" && ln -s "../libnghttp2.la" "libnghttp2.la" )
Server > file -b -L work/nghttp2-1.33.0/lib/.libs/libnghttp2.so
ELF 64-bit LSB pie executable, x86-64, version 1 (FreeBSD), dynamically linked, not stripped
????
I’m stumped.

I found that "pie" = position independent executable, but why executable and not shared library?
 
Does this build line seem reasonable to you?
Code: 
libtool: compile:  cc -DHAVE_CONFIG_H -I. -I.. -I./includes -I./includes -DBUILDING_NGHTTP2 -DHAVE_CONFIG_H -fvisibility=hidden -O2 -pipe -fstack-protector -fno-strict-aliasing -MT nghttp2_rcbuf.lo -MD -MP -MF .deps/nghttp2_rcbuf.Tpo -c nghttp2_rcbuf.c  -fPIC -DPIC -o .libs/nghttp2_rcbuf.o
Note the -fPIC and -DPIC which produce "PIC" code. Linking is done with the same flags:
Code: 
libtool: link: cc -shared  -fPIC -DPIC  .libs/nghttp2_pq.o .libs/nghttp2_map.o .libs/nghttp2_queue.o .libs/nghttp2_frame.o .libs/nghttp2_buf.o .libs/nghttp2_stream.o .libs/nghttp2_outbound_item.o .libs/nghttp2_session.o .libs/nghttp2_submit.o .libs/nghttp2_helper.o .libs/nghttp2_npn.o .libs/nghttp2_hd.o .libs/nghttp2_hd_huffman.o .libs/nghttp2_hd_huffman_data.o .libs/nghttp2_version.o .libs/nghttp2_priority_spec.o .libs/nghttp2_option.o .libs/nghttp2_callbacks.o .libs/nghttp2_mem.o .libs/nghttp2_http.o .libs/nghttp2_rcbuf.o .libs/nghttp2_debug.o    -O2 -fstack-protector -fstack-protector   -Wl,-soname -Wl,libnghttp2.so.14 -o .libs/libnghttp2.so.14.17.0
 
Ok, as a patch, I added application/x-pie-executable as a type of share lib recognized by /usr/ports/Mk/Scripts/find-lib.sh. The ports system now works as expected again.
Code: 
Server > sudo make build
===>   curl-7.61.1 depends on executable: gmake - found
===>   curl-7.61.1 depends on package: pkgconf>=1.3.0_1 - found
===>   curl-7.61.1 depends on package: perl5>=5.26<5.27 - found
===>   curl-7.61.1 depends on shared library: libnghttp2.so - found (/usr/local/lib/libnghttp2.so)
[…]
 
You must log in or register to reply here.
Back
Top