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



## Vincent Habchi (Sep 27, 2018)

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:


```
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:

```
Server > file -b -L --mime-type /lib/libm.so.5
application/x-sharedlib
```

Any idea what cause could this?
Also:

```
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!


----------



## SirDice (Sep 27, 2018)

I suspect your /usr/share/misc/magic got corrupted at some point:

```
dice@armitage:~ % file -b -L --mime-type /usr/local/lib/libnghttp2.so
application/x-sharedlib
```


----------



## Vincent Habchi (Sep 27, 2018)

SirDice said:


> I suspect your /usr/share/misc/magic got corrupted at some point:
> 
> ```
> dice@armitage:~ % file -b -L --mime-type /usr/local/lib/libnghttp2.so
> ...


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.

```
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.


----------



## Vincent Habchi (Sep 27, 2018)

Could you post your rmd160? Thanks!

```
Server > rmd160 /usr/share/misc/magic
RMD160 (/usr/share/misc/magic) = 6e457f20d7c7601fbe2b2abb5418d5f1181a294c
```


----------



## SirDice (Sep 27, 2018)

```
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:

```
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"......|
```


----------



## Vincent Habchi (Sep 27, 2018)

I copied the file to my MacBook Air and tried MacOS's file(1), same result:

```
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?


----------



## Vincent Habchi (Sep 27, 2018)

Darn 


```
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?


----------



## SirDice (Sep 27, 2018)

I had to lookup what PIE actually is: https://codywu2010.wordpress.com/2014/11/29/about-elf-pie-pic-and-else/

So this points me to compiler flags and similar options. What's in /etc/make.conf?


----------



## Vincent Habchi (Sep 27, 2018)

SirDice said:


> I had to lookup what PIE actually is: https://codywu2010.wordpress.com/2014/11/29/about-elf-pie-pic-and-else/
> 
> So this points me to compiler flags and similar options. What's in /etc/make.conf?



Yeah, I had the same idea. But my /etc/make.conf is all commented out but for Python and Perl DEFAULT_VERSIONS at the very end… :/


----------



## Vincent Habchi (Sep 27, 2018)

Does this build line seem reasonable to you?

```
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:

```
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
```


----------



## Vincent Habchi (Sep 29, 2018)

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.

```
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)
[…]
```


----------

