he's dead jim
Posts: 27
Joined: Wed Dec 09, 2015 3:35 am

Files Are Compiled As Shared Libraries Instead Of Executables

Mon Feb 05, 2018 12:03 am

I have researched this problem and apparently as of debian stretch, the pie function which was previously default off has been made default on.

not sure what that means as i am only a novice when it come to coding but the answer seems to be to use the following when compiling:

gcc main.c -o main -no-pie

the problem is, none of the many threads that i searched actually showed me how to use this, or where to use this. for example. when i am in the source directory, most of the time i have to just use:

qmake
make

with the particular source that i am trying to compile right now, i use:

./autogen.sh
./configure --with-incompatible-bdb --with-boost-libdir=/usr/lib/i386-linux-gnu
make

how and where do i put that gcc line in to make it work?

thanks :)

User avatar
scruss
Posts: 2615
Joined: Sat Jun 09, 2012 12:25 pm
Location: Toronto, ON
Contact: Website

Re: Files Are Compiled As Shared Libraries Instead Of Executables

Mon Feb 05, 2018 1:46 am

What are you trying to build? Boost applications can be a bit of a pain, but usually installing libboost-all-dev fixes that:

Code: Select all

sudo apt install libboost-all-dev
It would help a lot to know what package you're trying to build.
‘Remember the Golden Rule of Selling: “Do not resort to violence.”’ — McGlashan.

he's dead jim
Posts: 27
Joined: Wed Dec 09, 2015 3:35 am

Re: Files Are Compiled As Shared Libraries Instead Of Executables

Mon Feb 05, 2018 2:30 am

it has nothing to do with boost or any particular file. i seems to be anything that i build.

sorry i forgot to say that pie stands for position-independent executable (PIE)

it is now turned on by default as of debian stretch.

if i compile the same source in debian jessie the source compiles just fine into an executable like it should.

just found this explanation for ubuntu but it's the same in debian stretch:

------------------------------------------------------------------------------------------------------------------------------------------------------------------

I have fixed this behavior by adding the following line on my project's .pro file in QT:

QMAKE_LFLAGS += -no-pie

The behavior is occurring because newer ubuntu distros set GCC default link flag -pie, which marks e_type as ET_DYN on the binary file. Consequently, the Operating System recognizes as Shared Library.

To work around it, it may be necessary to add -no-pie on compiler option.

------------------------------------------------------------------------------------------------------------------------------------------------------------------

i'm gonna try editing the pro file and see if it compiles

he's dead jim
Posts: 27
Joined: Wed Dec 09, 2015 3:35 am

Re: Files Are Compiled As Shared Libraries Instead Of Executables

Mon Feb 05, 2018 3:44 am

tried a few compiles and didn't work.

gonna go back to jessie for now. if anyone finds a solution please post it in this thread.

this problem is common across many versions of linux including ubuntu, debian, arch and raspbian, all starting with stretch.

jessie does not have this problem.

User avatar
jojopi
Posts: 3085
Joined: Tue Oct 11, 2011 8:38 pm

Re: Files Are Compiled As Shared Libraries Instead Of Executables

Mon Feb 05, 2018 6:01 am

he's dead jim wrote:
Mon Feb 05, 2018 2:30 am
The behavior is occurring because newer ubuntu distros set GCC default link flag -pie, which marks e_type as ET_DYN on the binary file. Consequently, the Operating System recognizes as Shared Library.
You have not explained how this matters.

Yes the compiler makes position independent executables by default, and the ELF headers say that such binaries are shared objects rather than executables. They still execute perfectly fine though. Most of the system binaries are built the same way.

he's dead jim
Posts: 27
Joined: Wed Dec 09, 2015 3:35 am

Re: Files Are Compiled As Shared Libraries Instead Of Executables

Mon Feb 05, 2018 12:41 pm

jojopi wrote:
Mon Feb 05, 2018 6:01 am
he's dead jim wrote:
Mon Feb 05, 2018 2:30 am
The behavior is occurring because newer ubuntu distros set GCC default link flag -pie, which marks e_type as ET_DYN on the binary file. Consequently, the Operating System recognizes as Shared Library.
You have not explained how this matters.

Yes the compiler makes position independent executables by default, and the ELF headers say that such binaries are shared objects rather than executables. They still execute perfectly fine though. Most of the system binaries are built the same way.
yes but when i try to execute the file i just get a pop-up asking to choose an application to open this file type with.

what do i choose?

how do i make it an executable?

any monkey can compile. it's just a few commands once you download the source.

most errors can be googled. in the end, i'm still just a user who doesn't know an ELF header from adam lol.

:)

User avatar
scruss
Posts: 2615
Joined: Sat Jun 09, 2012 12:25 pm
Location: Toronto, ON
Contact: Website

Re: Files Are Compiled As Shared Libraries Instead Of Executables

Tue Feb 06, 2018 4:27 am

Works fine here on a VirtualBox installation of the RP Desktop:
Screenshot from 2018-02-05 23-18-01.png
simple c build
Screenshot from 2018-02-05 23-18-01.png (48.29 KiB) Viewed 4163 times
But you're right, if you use the file manager to launch files, it shows up as "shared library" and won't run.

I guess no-one uses the file manager, then …
‘Remember the Golden Rule of Selling: “Do not resort to violence.”’ — McGlashan.

he's dead jim
Posts: 27
Joined: Wed Dec 09, 2015 3:35 am

Re: Files Are Compiled As Shared Libraries Instead Of Executables

Tue Feb 06, 2018 5:06 am

Thanks.

I appreciate you trying and confirming it. Unfortunately the stuff that i compile relies on being executed with a double click from the icon on the desktop.

I looked at the properties of the existing icons but I can't find anything helpful.

If I knew what to associate the icon with i'd be in business.

ghans
Posts: 7878
Joined: Mon Dec 12, 2011 8:30 pm
Location: Germany

Re: Files Are Compiled As Shared Libraries Instead Of Executables

Tue Feb 06, 2018 7:24 am

Shortcuts on freedesktop.org compatible desktops are text files.

https://wiki.archlinux.org/index.php/desktop_entries

ghans
• Don't like the board ? Missing features ? Change to the prosilver theme ! You can find it in your settings.
• Don't like to search the forum BEFORE posting 'cos it's useless ? Try googling : yoursearchtermshere site:raspberrypi.org

he's dead jim
Posts: 27
Joined: Wed Dec 09, 2015 3:35 am

Re: Files Are Compiled As Shared Libraries Instead Of Executables

Tue Feb 06, 2018 1:53 pm

I have confirmed that this does work:

------------------------------------------------------------------------------------------------------------------------------
I have fixed this behavior by adding the following line on my project's .pro file in QT:

QMAKE_LFLAGS += -no-pie
------------------------------------------------------------------------------------------------------------------------------

however, in my opinion ther should be a better way to do this.

there are gonna be a lot of cross compatibility issues between jessie and stretch for the people i compile for.

i'm talking hundreds of source files.

PhilE
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 2480
Joined: Mon Sep 29, 2014 1:07 pm
Location: Cambridge

Re: Files Are Compiled As Shared Libraries Instead Of Executables

Tue Feb 06, 2018 3:18 pm

Let's start from the basics: build a program with and without the -no-pie flag and post the output of "file <progname>" (where <progname> is the name of the executable) for both versions.

User avatar
scruss
Posts: 2615
Joined: Sat Jun 09, 2012 12:25 pm
Location: Toronto, ON
Contact: Website

Re: Files Are Compiled As Shared Libraries Instead Of Executables

Tue Feb 06, 2018 4:58 pm

PhilE wrote:
Tue Feb 06, 2018 3:18 pm
Let's start from the basics: build a program with and without the -no-pie flag and post the output of "file <progname>" (where <progname> is the name of the executable) for both versions.
file alone doesn't catch it, Phil. This bug also affects x86_64, and I've just dropped a bug on Ubuntu about this. Here's my bug summary - please excuse x86_64, I assure you it's present on Raspberry Pi Desktop 32-bit/x86:

Code: Select all

Expected behaviour:

    $ echo "int main() { return 0; }" > foo.c
    $ gcc -o foo foo.c
    $ file foo
    foo: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 3.2.0, BuildID[sha1]=6e7749f995a89a53f74ec29d3c16fcf3f56be90f, not stripped
    $ file --mime-type foo
    foo: application/x-executable

Actual behaviour:

    $ echo "int main() { return 0; }" > foo.c
    $ gcc -o foo foo.c
    $ file foo
    foo: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 3.2.0, BuildID[sha1]=6e7749f995a89a53f74ec29d3c16fcf3f56be90f, not stripped
    $ file --mime-type foo
    foo: application/x-sharedlib

Workaround:

    $ echo "int main() { return 0; }" > foo.c
    $ gcc -o foo-nopie foo.c -no-pie
    $ file foo-nopie
    foo-nopie: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 3.2.0, BuildID[sha1]=3eb8c581f43c19997e3c828f5a9730dbdc794470, not stripped
    $ file --mime-type foo-nopie 
    foo-nopie: application/x-executable
gcc now defaults to building with PIE (Position Independent Executable) enabled on x86 Debian systems for security reasons. So it's likely an upstream bug in file that's preventing PCManFM from correctly running executables. This doesn't seem to affect ARM.

he's dead jim: while compiling with -no-pie is a short-term workaround, it may also be a security risk for your users.
‘Remember the Golden Rule of Selling: “Do not resort to violence.”’ — McGlashan.

PhilE
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 2480
Joined: Mon Sep 29, 2014 1:07 pm
Location: Cambridge

Re: Files Are Compiled As Shared Libraries Instead Of Executables

Tue Feb 06, 2018 5:04 pm

Including hard information makes it so much easier to Google stackoverflow: https://stackoverflow.com/questions/413 ... -applicati

he's dead jim
Posts: 27
Joined: Wed Dec 09, 2015 3:35 am

Re: Files Are Compiled As Shared Libraries Instead Of Executables

Tue Feb 06, 2018 6:29 pm

scruss wrote:
Tue Feb 06, 2018 4:58 pm
he's dead jim: while compiling with -no-pie is a short-term workaround, it may also be a security risk for your users.
yep thanks :)

i just wanted to see if it did work as advertised.

i'd much rather find a way for it to work with pie enabled as extra security is never a bad thing.

n67
Posts: 938
Joined: Mon Oct 30, 2017 4:55 pm

Re: Files Are Compiled As Shared Libraries Instead Of Executables

Tue Feb 06, 2018 6:46 pm

Two questions:

1) Why is compiling with -pie more "secure" ?
Note: I am quite familiar with -pie and what it does; I use it when I want to compile a program in such a way that a single file will function as either an executable or a shared library.

2) Why is your version of "file" displaying "shared object" when you are compiling it as a straight up executable? Normally, file displays something like "LSB executable" for executables. See below:

Code: Select all

$ file /bin/ls
/bin/ls: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux-armhf.so.3, for GNU/Linux 2.6.32, BuildID[sha1]=5e052e8de057d379ab51d4af510ad9318fe77b46, stripped
$ file /lib/libnih.so.1.0.0 
/lib/libnih.so.1.0.0: ELF 32-bit LSB shared object, ARM, EABI5 version 1 (SYSV), dynamically linked, BuildID[sha1]=46a359631e3df17e1d934ed02d4a4651f3c52921, stripped

"L'enfer, c'est les autres"

G fytc hsqr rum umpbq rm qyw rm rfc kmbq md rfgq dmpsk:

Epmu Sn!

J lnacjrw njbruh-carppnanm vxm rb mnuncrwp vh yxbcb!

User avatar
scruss
Posts: 2615
Joined: Sat Jun 09, 2012 12:25 pm
Location: Toronto, ON
Contact: Website

Re: Files Are Compiled As Shared Libraries Instead Of Executables

Tue Feb 06, 2018 9:11 pm

n67 wrote:
Tue Feb 06, 2018 6:46 pm
1) Why is compiling with -pie more "secure" ?
It apparently allows Address space layout randomization (ASLR), which is supposed to make it harder to guess where a process's stack and other squishy bits are in memory.
2) Why is your version of "file" displaying "shared object" when you are compiling it as a straight up executable? Normally, file displays something like "LSB executable" for executables.
Depends on the platform. Under Raspbian, I get "ELF 32-bit LSB executable". On x86 and Beaglebone (Debian 9), I get "ELF __-bit LSB shared object" for PIE executables, and "ELF __-bit LSB executable," for no-pie ones.
‘Remember the Golden Rule of Selling: “Do not resort to violence.”’ — McGlashan.

PhilE
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 2480
Joined: Mon Sep 29, 2014 1:07 pm
Location: Cambridge

Re: Files Are Compiled As Shared Libraries Instead Of Executables

Wed Feb 07, 2018 11:31 am

My findings are slightly different, but I agree that Position Independent Executables confuse the mimetype mechanism.

In the most recent Raspbian Stretch image (Nov 29th 2017) gcc generates normal position-dependent code by default, but I can believe that somewhere the default has changed. Adding '-pie' to the GCC creates the position-independent version.

In this output, pdfoo is the normal position-dependent elf, and pifoo is position-independent:

Code: Select all

[email protected]:~ $ file pdfoo
pdfoo: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux-armhf.so.3, for GNU/Linux 3.2.0, BuildID[sha1]=4595b7b91b4664bb34eea3a09fb3b27af4c0596a, not stripped
[email protected]:~ $ file -i pdfoo
pdfoo: application/x-executable; charset=binary
[email protected]:~ $ hexdump pdfoo | head -2
0000000 457f 464c 0101 0001 0000 0000 0000 0000
0000010 0002 0028 0001 0000 02e0 0001 0034 0000

[email protected]:~ $ file pifoo
pifoo: ELF 32-bit LSB shared object, ARM, EABI5 version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux-armhf.so.3, for GNU/Linux 3.2.0, BuildID[sha1]=3c6fe8043dec1156c0b9b85e73ce48635e4f1cca, not stripped
[email protected]:~ $ file -i pifoo
pifoo: application/x-sharedlib; charset=binary
[email protected]:~ $ hexdump pifoo | head -2
0000000 457f 464c 0101 0001 0000 0000 0000 0000
0000010 0003 0028 0001 0000 0468 0000 0034 0000
The "file" utility uses a file of magic numbers to identify file types. The following section of the source shows how the decision is made: [ From https://github.com/file/file/blob/a25f2 ... ir/elf#L44 ]

Code: Select all

0	name		elf-le
>16	leshort		0		no file type,
!:mime	application/octet-stream
>16	leshort		1		relocatable,
!:mime	application/x-object
>16	leshort		2		executable,
!:mime	application/x-executable
>16	leshort		3		shared object,
!:mime	application/x-sharedlib
>16	leshort		4		core file
!:mime	application/x-coredump
According to my limited understanding the 16-bit little-endian value at offset 16 determines the ELF sub-type. As you can see in the hex dumps above, pdfoo has 2 (executable) while pifoo has 3 (shared object).

The takeaway from this seems to be that while position-independent code may be better from a security perspective, the current implementation is a hack that confuses "file".

User avatar
scruss
Posts: 2615
Joined: Sat Jun 09, 2012 12:25 pm
Location: Toronto, ON
Contact: Website

Re: Files Are Compiled As Shared Libraries Instead Of Executables

Wed Feb 07, 2018 10:14 pm

It turns out that the original developer of file is local to me and I've met him a few times. I'm getting contact details for the current maintainer soon, I hope.

Update: they've decided to fix it, but I don't know how long before this change will flow through to user distributions.
‘Remember the Golden Rule of Selling: “Do not resort to violence.”’ — McGlashan.

he's dead jim
Posts: 27
Joined: Wed Dec 09, 2015 3:35 am

Re: Files Are Compiled As Shared Libraries Instead Of Executables

Fri Feb 09, 2018 12:43 pm

scruss wrote:
Wed Feb 07, 2018 10:14 pm
It turns out that the original developer of file is local to me and I've met him a few times. I'm getting contact details for the current maintainer soon, I hope.

Update: they've decided to fix it, but I don't know how long before this change will flow through to user distributions.
Thanks.

That's awesome. I really appreciated it and I'm surre a great many others will as well.

:)

Return to “Raspberry Pi Desktop for PC and Mac”