On Jun 16, 2015 7:42 PM, "Christos Zoulas" <chris...@zoulas.com> wrote: > > On Jun 16, 7:54pm, rhin...@epost.ch (rhin...@epost.ch) wrote: > -- Subject: Re: Security and PAX > > | On Mon, Jun 15, 2015 at 09:59:34AM -0400, Christos Zoulas wrote: > | > On Jun 15, 9:15am, rhin...@epost.ch (rhin...@epost.ch) wrote: > | > -- Subject: Re: Security and PAX > | > > | > | I will send you this info soon. Should I recompile Userland programs and libs > | > | with the parameter "-fpic". If I remember well, it was the library > | > | "libtermcap" (from userland) which cannot be linked and the error > | > | message suggested to compile it with "-fpic". > | > > | > Ah, for this link all the archive libraries into the binary you need to create > | > libfoo_pic.a for each one of them like you have for libc... It is not hard > | > to do, but we don't do it by default because people don't need it and it > | > takes more time and space. > | > > | The needed libraries are already in NetBSD and I could use them. > | Hoewever, I get a new error message when I try to do manually > | the link command: > | ---------------------------------------------------------------------------------------------- > | virtualisation# cc -static -Wl,-I/libexec/ld.elf_so -Wl,-pie -o zsh main.o `cat stamp-modobjs` -lc_pic -ltermcap_pic -lrt_pic -lm_pic > | ld: /usr/lib/libc.a(errx.o): relocation R_X86_64_32 against `.text' can not be used when making a shared object; recompile with -fPIC > | /usr/lib/libc.a: could not read symbols: Bad value > | ---------------------------------------------------------------------------------------------- > | > | I don't understand well the meaning of "R_X86_64_32" since I compile > | in 64 bits (what mean "32"?) as you can see in the static version of the executable: > > This means that you are picking up some code that it is not PIC; the 32 here > means 32 bit offsets. > > The order of the libraries is wrong, you need to put -lc_pic last because > the others depend on symbols from it. There is a way to cheat by repeating > all the libraries twice :-) >
--start-group libs --end-group is the cleaner way to say they have interdependencies... Justin
