Compilation error

Compilation error

[nicolas]

Hello ! (it's me again...)

I tried to compile musl with the pcc compiler, but it failed because of :

$(CC) $(LDFLAGS) -Wl,-soname=libc.so -o $@ $(LOBJS) -lgcc

Is the option -lgcc really necessary ?
I had removed it, and the compilation succeeded :)

Musl should be compilable with any C Compiler i mean...

Cheers,
Nick

Re: Compilation error

[Rich Felker]

On Sun, Aug 07, 2011 at 09:36:58PM +0200, Szabolcs Nagy wrote:
> * nicolas@atelier-web.com <nicolas@atelier-web.com> [2011-08-07 20:57:11 +0200]:
> > I tried to compile musl with the pcc compiler, but it failed because of :
> > 
> > $(CC) $(LDFLAGS) -Wl,-soname=libc.so -o $@ $(LOBJS) -lgcc
> > 
> > Is the option -lgcc really necessary ?
> > I had removed it, and the compilation succeeded :)
> 
> with pcc you don't need -lgcc obviously
> with gcc you need it

Doesn't pcc have its own equivalent library with the same functions
for big division, etc.?

This makes me think more and more I should just add the essential
functions to musl. That way we could make them faster and less
bloated. There are only a few that are actually useful anyway (at
least to libc) and for the rest apps/libraries can just pull in their
own copy from libgcc or libpcc via the compiler's default library
searches.

> btw pcc cannot build a correct musl now
> clock_gettime refers to a weak symbol
> but pcc does not know __attribute__((weak))
> so __vdso_clock_gettime ends up being
> an undefined symbol
> 
> (there are various kinds of weakref related
> attributes and it's a known defect in pcc
> http://pcc.ludd.ltu.se/jira/browse/PCC-362 )
> 
> musl mostly uses weak aliases which happen
> to work with pcc imho clock_gettime is the
> only exception..

I'll try to work up a fix...

Rich

Re: Compilation error

[Szabolcs Nagy]

* nicolas@atelier-web.com <nicolas@atelier-web.com> [2011-08-07 20:57:11 +0200]:
> I tried to compile musl with the pcc compiler, but it failed because of :
> 
> $(CC) $(LDFLAGS) -Wl,-soname=libc.so -o $@ $(LOBJS) -lgcc
> 
> Is the option -lgcc really necessary ?
> I had removed it, and the compilation succeeded :)

with pcc you don't need -lgcc obviously
with gcc you need it

btw pcc cannot build a correct musl now
clock_gettime refers to a weak symbol
but pcc does not know __attribute__((weak))
so __vdso_clock_gettime ends up being
an undefined symbol

(there are various kinds of weakref related
attributes and it's a known defect in pcc
http://pcc.ludd.ltu.se/jira/browse/PCC-362 )

musl mostly uses weak aliases which happen
to work with pcc imho clock_gettime is the
only exception..

Re: Compilation error

[Rich Felker]

On Sun, Aug 07, 2011 at 03:34:31PM -0400, Rich Felker wrote:
> > btw pcc cannot build a correct musl now
> > clock_gettime refers to a weak symbol
> > but pcc does not know __attribute__((weak))
> > so __vdso_clock_gettime ends up being
> > an undefined symbol
> > 
> > (there are various kinds of weakref related
> > attributes and it's a known defect in pcc
> > http://pcc.ludd.ltu.se/jira/browse/PCC-362 )
> > 
> > musl mostly uses weak aliases which happen
> > to work with pcc imho clock_gettime is the
> > only exception..
> 
> I'll try to work up a fix...

It should be working with latest commit. If not, please tell me what
goes wrong.

Rich

Re: Compilation error

[Rich Felker]

On Sun, Aug 07, 2011 at 11:01:45PM +0200, nicolas@atelier-web.com wrote:
> Thanks for the fix, i'll test that tomorrow :)
> And for -lgcc ? It would be great if i didn't have to modify the makefile
> at every compilation...

I don't know any clean fix on my side until I add replacements for all
of the libgcc functions (and I'm still waiting to make sure nobody has
strong and valid objections to that). Can you confirm that it even
works on pcc without -lgcc? Or..maybe you're on a 64-bit machine where
64-bit division is native and you don't need libgcc for it.

I would just make libgcc.a a symlink to libpcc.a or make it an empty
.a file if it's not needed... That's an easy workaround for now that
will avoid having to fiddle with the Makefile.

Rich

Re: Compilation error

[nicolas]

Thanks for the fix, i'll test that tomorrow :)
And for -lgcc ? It would be great if i didn't have to modify the makefile
at every compilation...

Nick

On Sun, 7 Aug 2011 15:50:06 -0400, Rich Felker <dalias@aerifal.cx> wrote:
> On Sun, Aug 07, 2011 at 03:34:31PM -0400, Rich Felker wrote:
>> > btw pcc cannot build a correct musl now
>> > clock_gettime refers to a weak symbol
>> > but pcc does not know __attribute__((weak))
>> > so __vdso_clock_gettime ends up being
>> > an undefined symbol
>> > 
>> > (there are various kinds of weakref related
>> > attributes and it's a known defect in pcc
>> > http://pcc.ludd.ltu.se/jira/browse/PCC-362 )
>> > 
>> > musl mostly uses weak aliases which happen
>> > to work with pcc imho clock_gettime is the
>> > only exception..
>> 
>> I'll try to work up a fix...
> 
> It should be working with latest commit. If not, please tell me what
> goes wrong.
> 
> Rich

Re: Compilation error

[Rich Felker]

On Mon, Aug 08, 2011 at 12:09:40AM +0200, Szabolcs Nagy wrote:
> * Rich Felker <dalias@aerifal.cx> [2011-08-07 15:50:06 -0400]:
> > It should be working with latest commit. If not, please tell me what
> > goes wrong.
> > 
> 
> it seems to work but i'm not sure what the code does
> 
> isn't it enough to
> weakalias(sc_clock_gettime, __vdso_clock_gettime);
> and then just use __vdso_clock_gettime ?
> 
> (so no __cgt etc)

No, because -Bsymbolic-functions binds it at link-time, or in other
words, libc.so is intentionally built with no PLT because that makes
it faster to start, faster to run, and lighter in memory.

Otherwise, without -Bsymbolic-functions, you would be right.

> (for some reason dynamic linking with musl fails now if i
> compile musl with pcc imho it used to work..)

Can you find where it fails?

Rich

Re: Compilation error

[Rich Felker]

On Sun, Aug 07, 2011 at 06:00:25PM -0400, Rich Felker wrote:
> > isn't it enough to
> > weakalias(sc_clock_gettime, __vdso_clock_gettime);
> > and then just use __vdso_clock_gettime ?
> > 
> > (so no __cgt etc)
> 
> No, because -Bsymbolic-functions binds it at link-time, or in other
> words, libc.so is intentionally built with no PLT because that makes
> it faster to start, faster to run, and lighter in memory.

By the way, it would be a lot nicer if we could use and rely on
visibility instead of -Bsymbolic-functions, so we could override the
behavior for a few specific functions. However, as far as I can tell
gcc (much less any other compiler) has no way to say "all functions
without explicit visibility should be protected, and all data without
explicit visibility should be default". So to use visibility we'd have
to have hideous attributes all over the place, which is pretty much
unacceptable...

Fortunately -Bsymbolic-functions is a close enough approximation to
what we want, and happens at the linker level instead of the compiler
level, so it's safe to use.

Rich

Re: Compilation error

[Szabolcs Nagy]

* Rich Felker <dalias@aerifal.cx> [2011-08-07 15:50:06 -0400]:
> It should be working with latest commit. If not, please tell me what
> goes wrong.
> 

it seems to work but i'm not sure what the code does

isn't it enough to
weakalias(sc_clock_gettime, __vdso_clock_gettime);
and then just use __vdso_clock_gettime ?

(so no __cgt etc)


(for some reason dynamic linking with musl fails now if i
compile musl with pcc imho it used to work..)

Re: Compilation error

[Szabolcs Nagy]

* Rich Felker <dalias@aerifal.cx> [2011-08-07 18:00:25 -0400]:
> > (for some reason dynamic linking with musl fails now if i
> > compile musl with pcc imho it used to work..)
> 
> Can you find where it fails?
> 

it can be a pcc bug
if i compile everything with pcc but link with gcc
then dynamic linking works

the only change to the linker flags is -L/path/to/pcclibs -lpcc
instead of -lgcc, so either pcc does not call ld properly
or there is some issue with -lpcc

pcc -v prints the way it calls the linker:
ld -v -X -shared -o lib/libc.so -e _start -Bsymbolic-functions -soname=libc.so [..src/*/*.lo..] -L/usr/local/lib/pcc/i686-pc-linux-gnu/1.1.0.DEVEL/lib/ -lpcc -g

i printed some variables right before do_single_reloc
(pcc debug info is not always reliable)
(type 8 is R_386_RELATIVE)


running in gdb:

type 8 sym_idex 0 reloc_addr 0xb785c37c *reloc_addr 0x8dc94 base 0xb77d1000 rel[0..2] 0x8b37c 0x8 0x8fdb4

Program received signal SIGSEGV, Segmentation fault.
0xb77ddda8 in do_single_reloc () at src/ldso/dynlink.c:148
148	}
(gdb) bt
#0  0xb77ddda8 in do_single_reloc () at src/ldso/dynlink.c:148
#1  0xb77ddcba in do_relocs (base=0xb77d1000 "\177ELF\001\001\001", start=<error type>, end=<error type>, 
    base=0xb77d1000 "\177ELF\001\001\001", start=<error type>, end=<error type>) at src/ldso/dynlink.c:146
#2  0xb77e048b in __dynlink () at src/ldso/dynlink.c:538
#3  0xb77e0abc in _start () from ../../lib/libc.so


running in valgrind:

type 8 sym_idex 0 reloc_addr 0x0408b37c *reloc_addr 0x8dc94 base 0x04000000 rel[0..2] 0x8b37c 0x8 0x8fdb4
==2261== 
==2261== Process terminating with default action of signal 11 (SIGSEGV)
==2261==  Bad permissions for mapped region at address 0x408B37C
==2261==    at 0x400CDA8: ??? (src/ldso/dynlink.c:148)
==2261==    by 0x400CCB9: ??? (src/ldso/dynlink.c:146)
==2261==    by 0x400F48A: __dynlink (src/ldso/dynlink.c:538)
==2261==    by 0x400FABB: (within /home/nsz/dev/lang/c/musl/lib/libc.so)


valgrind says it's permission problem so i printed smaps

smaps with pcc:

type 8 sym_idex 0 reloc_addr 0xb78ac1ec *reloc_addr 0x62544 base 0xb7863000 rel[0..2] 0x491ec 0x8 0x63000
...
b7862000-b7863000 r-xp b7862000 00:00 0          [vdso]
Size:                  4 kB
Rss:                   4 kB
Pss:                   0 kB
Shared_Clean:          4 kB
Shared_Dirty:          0 kB
Private_Clean:         0 kB
Private_Dirty:         0 kB
Referenced:            4 kB
Swap:                  0 kB
b7863000-b78c6000 r-xp 00000000 08:01 1581497    /home/nsz/dev/lang/c/musl/lib/libc.so
Size:                396 kB
Rss:                  68 kB
Pss:                  68 kB
Shared_Clean:          0 kB
Shared_Dirty:          0 kB
Private_Clean:        68 kB
Private_Dirty:         0 kB
Referenced:           68 kB
Swap:                  0 kB
b78c6000-b78c7000 rwxp 00063000 08:01 1581497    /home/nsz/dev/lang/c/musl/lib/libc.so
Size:                  4 kB
Rss:                   4 kB
Pss:                   4 kB
Shared_Clean:          0 kB
Shared_Dirty:          0 kB
Private_Clean:         0 kB
Private_Dirty:         4 kB
Referenced:            4 kB
Swap:                  0 kB
...


smaps when linked with gcc (no segfault):

type 8 sym_idex 0 reloc_addr 0xb77c5ea4 *reloc_addr 0xdd40 base 0xb7760000 rel[0..2] 0x65ea4 0x8 0x65ea8
...
b775f000-b7760000 r-xp b775f000 00:00 0          [vdso]
Size:                  4 kB
Rss:                   4 kB
Pss:                   0 kB
Shared_Clean:          4 kB
Shared_Dirty:          0 kB
Private_Clean:         0 kB
Private_Dirty:         0 kB
Referenced:            4 kB
Swap:                  0 kB
b7760000-b77c5000 r-xp 00000000 08:01 5638271    /home/nsz/dev/lang/c/musl/lib/libc.so
Size:                404 kB
Rss:                  72 kB
Pss:                  72 kB
Shared_Clean:          0 kB
Shared_Dirty:          0 kB
Private_Clean:        72 kB
Private_Dirty:         0 kB
Referenced:           72 kB
Swap:                  0 kB
b77c5000-b77c7000 rwxp 00064000 08:01 5638271    /home/nsz/dev/lang/c/musl/lib/libc.so
Size:                  8 kB
Rss:                   8 kB
Pss:                   8 kB
Shared_Clean:          0 kB
Shared_Dirty:          0 kB
Private_Clean:         0 kB
Private_Dirty:         8 kB
Referenced:            8 kB
Swap:                  0 kB
...

Make

[nicolas]

Yop !

Now, i'm able to compile and to run musl as the only system of the system
(chroot) but there 2 things that i don't understand.

1) There is no /lib/ld-linux.so.2 ?
2) How can i link programs with musl if i don't use gcc ?

For example, i managed to compile Make 3.82 with pcc :
CC=pcc ./configure --prefix=/usr \
--build=i586-pc-linux-gnu --host=i586-pc-linux-gnu
CC=pcc make
CC=pcc make install

But make depends on ld-linux.so.2 ans on librt.so.1 which are not provided
by musl..
How should i build it ?

Cheers,
Nick

P.S : scuse me for my noobs questions...

Re: Make

[Rich Felker]

On Mon, Aug 08, 2011 at 03:03:09PM +0200, nicolas@atelier-web.com wrote:
> Yop !
> 
> Now, i'm able to compile and to run musl as the only system of the system
> (chroot) but there 2 things that i don't understand.
> 
> 1) There is no /lib/ld-linux.so.2 ?

/lib/ld-musl-i386.so.1

If you're building a native compiler rather than using the wrapper you
should edit the specs to point the linker here (-dynamic-linker option).

> 2) How can i link programs with musl if i don't use gcc ?
> 
> For example, i managed to compile Make 3.82 with pcc :
> CC=pcc ./configure --prefix=/usr \
> --build=i586-pc-linux-gnu --host=i586-pc-linux-gnu
> CC=pcc make
> CC=pcc make install

You should not need --build or --host unless you're doing weird
cross-compiling stuff. In a native environment (which you have) just
CC=pcc ./configure --prefix=/usr && make should be all you need.

> But make depends on ld-linux.so.2 ans on librt.so.1 which are not provided

musl provides an empty librt.a which should satisfy anything using
-lrt. All standard library functions are in the main library; it's not
broken down into parts because that just makes the system slow,
bloated, and harder to maintain.

Rich

Re: Make

[Rich Felker]

On Mon, Aug 08, 2011 at 03:03:09PM +0200, nicolas@atelier-web.com wrote:
> But make depends on ld-linux.so.2 ans on librt.so.1 which are not provided
> by musl..

Actually maybe I misunderstood - are you trying to use a glibc-linked
"make" in a chroot that only has musl? If so, it won't work. You could
instead static-link all your glibc programs (so they'll work in the
chroot) then replace them with musl-linked ones as soon as you can..

Rich

Re: Make

[nicolas]

On Mon, 8 Aug 2011 16:56:18 -0400, Rich Felker <dalias@aerifal.cx> wrote:
> On Mon, Aug 08, 2011 at 03:03:09PM +0200, nicolas@atelier-web.com wrote:
>> But make depends on ld-linux.so.2 ans on librt.so.1 which are not
>> provided
>> by musl..
> 
> Actually maybe I misunderstood - are you trying to use a glibc-linked
> "make" in a chroot that only has musl? If so, it won't work. You could
> instead static-link all your glibc programs (so they'll work in the
> chroot) then replace them with musl-linked ones as soon as you can..
> 
> Rich

Hmm,
Okay, thanks for these explanations :)
I tried something, i began to try to use the gcc wrapper to link make to
musl,
but i had some errors : some headers were missing (ar.h / sys/cdefs.h)
So I tried to use the system's headers (Archlinux) but the compilation
failed. (copy to /usr/local/musl/include)

I know, i have a lot of problems, i'm really bad :D

Nick

Re: Make

[Rich Felker]

On Tue, Aug 09, 2011 at 09:10:23PM +0200, nicolas@atelier-web.com wrote:
> On Mon, 8 Aug 2011 16:56:18 -0400, Rich Felker <dalias@aerifal.cx> wrote:
> > On Mon, Aug 08, 2011 at 03:03:09PM +0200, nicolas@atelier-web.com wrote:
> >> But make depends on ld-linux.so.2 ans on librt.so.1 which are not
> >> provided
> >> by musl..
> > 
> > Actually maybe I misunderstood - are you trying to use a glibc-linked
> > "make" in a chroot that only has musl? If so, it won't work. You could
> > instead static-link all your glibc programs (so they'll work in the
> > chroot) then replace them with musl-linked ones as soon as you can..
> > 
> > Rich
> 
> Hmm,
> Okay, thanks for these explanations :)
> I tried something, i began to try to use the gcc wrapper to link make to
> musl,
> but i had some errors : some headers were missing (ar.h / sys/cdefs.h)

I'm doubtful that make was trying to include sys/cdefs.h. I certainly
never ran into this issue when building it. It may try ar.h, but
configure should really be detecting the presence or absence of these.
Are you trying to use a make source tree that was already configured
for glibc?

> So I tried to use the system's headers (Archlinux) but the compilation
> failed. (copy to /usr/local/musl/include)

This is definitely wrong, in general. If a program is trying to
include a header that doesn't exist, the first thing you try should be
just removing the #include line. :-)

Rich

Re: Make

[Szabolcs Nagy]

* nicolas@atelier-web.com <nicolas@atelier-web.com> [2011-08-09 21:10:23 +0200]:
> but i had some errors : some headers were missing (ar.h / sys/cdefs.h)

i used this one
http://sourceware.org/cgi-bin/cvsweb.cgi/src/include/aout/ar.h?rev=1.5&cvsroot=src

if you build binutils for your chroot then you can copy it from there..

Re: Make

[nicolas]

On Tue, 9 Aug 2011 22:23:06 +0200, Szabolcs Nagy <nsz@port70.net> wrote:
> * nicolas@atelier-web.com <nicolas@atelier-web.com> [2011-08-09 21:10:23
> +0200]:
>> but i had some errors : some headers were missing (ar.h / sys/cdefs.h)
> 
> i used this one
>
http://sourceware.org/cgi-bin/cvsweb.cgi/src/include/aout/ar.h?rev=1.5&cvsroot=src
> 
> if you build binutils for your chroot then you can copy it from there..

Thanks, it works now :)
In fact, the ar.h taht i was using needed sys/cdefs.h...
I managed to compile some static packages in a musl-based system (using
pcc compiler) and i were able to use the musl-gcc wrapper, but in static
too,
Is it possible to do a dynamic link with the wrapper ?

Nick

Re: Compilation error

[Szabolcs Nagy]

* Szabolcs Nagy <nsz@port70.net> [2011-08-08 09:08:17 +0200]:

> * Rich Felker <dalias@aerifal.cx> [2011-08-07 18:00:25 -0400]:
> > > (for some reason dynamic linking with musl fails now if i
> > > compile musl with pcc imho it used to work..)
> > 
> > Can you find where it fails?
> > 
> 

> the only change to the linker flags is -L/path/to/pcclibs -lpcc
> instead of -lgcc, so either pcc does not call ld properly
> or there is some issue with -lpcc
> 

i've just rechecked this and the problem simply was that
libpcc.a was not compiled with -fPIC

(it used to work because i didn't specify -lpcc when building libc.so
and later i only tried dynamic linking with pcc
which adds -lpcc automatically so there were no missing symbols)


but i guess it would be nice if musl implemented long long arithmetics
and made -lpcc/-lgcc unnecessary
(i'm not sure where alloca should go, pcc does not provide it)

Re: Compilation error

[Rich Felker]

On Wed, Aug 17, 2011 at 12:33:28PM +0200, Szabolcs Nagy wrote:
> > the only change to the linker flags is -L/path/to/pcclibs -lpcc
> > instead of -lgcc, so either pcc does not call ld properly
> > or there is some issue with -lpcc
> > 
> 
> i've just rechecked this and the problem simply was that
> libpcc.a was not compiled with -fPIC

It's disturbing that this made a difference. There should be no global
data needed by libpcc, and if there is some needed, I question what
it's doing and whether it's really safe...

> (it used to work because i didn't specify -lpcc when building libc.so
> and later i only tried dynamic linking with pcc
> which adds -lpcc automatically so there were no missing symbols)

This still need not work; it will result in PLT relocations in libc.so
which could crash if libpcc is needed prior to relocation. And it will
badly hurt runtime performance.

> but i guess it would be nice if musl implemented long long arithmetics
> and made -lpcc/-lgcc unnecessary

Yes..

> (i'm not sure where alloca should go, pcc does not provide it)

WTF? alloca cannot be implemented as a function. Does gcc provide an
alloca function?

Rich

Re: Compilation error

[Szabolcs Nagy]

* Rich Felker <dalias@aerifal.cx> [2011-08-17 09:39:13 -0400]:
> > (i'm not sure where alloca should go, pcc does not provide it)
> 
> WTF? alloca cannot be implemented as a function. Does gcc provide an
> alloca function?
> 

i'm not sure how it should work but
__alloca is defined in libpcc using simple asm trickery
(modify stackpointer and the values on the stack and return)
so in case of pcc CFLAGS+=-Dalloca=__alloca works

tcc seems to implement alloca similarly in libtcc
but they call it alloca so no define is needed

glibc defines alloca as __builtin_alloca if gcc is used
for compilation otherwise it just provides an extern
declaration for it

Re: Compilation error

[Szabolcs Nagy]

* Szabolcs Nagy <nsz@port70.net> [2011-08-17 16:47:24 +0200]:

> * Rich Felker <dalias@aerifal.cx> [2011-08-17 09:39:13 -0400]:
> > > (i'm not sure where alloca should go, pcc does not provide it)
> > 
> > WTF? alloca cannot be implemented as a function. Does gcc provide an
> > alloca function?
> > 
> 
> i'm not sure how it should work but
> __alloca is defined in libpcc using simple asm trickery
> (modify stackpointer and the values on the stack and return)
> so in case of pcc CFLAGS+=-Dalloca=__alloca works

sorry
pcc has __builtin_alloca
so -Dalloca=__builtin_alloca works

Re: Compilation error

[Rich Felker]

On Wed, Aug 17, 2011 at 04:47:24PM +0200, Szabolcs Nagy wrote:
> * Rich Felker <dalias@aerifal.cx> [2011-08-17 09:39:13 -0400]:
> > > (i'm not sure where alloca should go, pcc does not provide it)
> > 
> > WTF? alloca cannot be implemented as a function. Does gcc provide an
> > alloca function?
> > 
> 
> i'm not sure how it should work but
> __alloca is defined in libpcc using simple asm trickery
> (modify stackpointer and the values on the stack and return)

This only works if there's a frame pointer and all automatic variable
access happens through the frame pointer. If the compiler generates
stack-pointer-relative accesses, it will break horribly. This is why
alloca really needs to be a builtin that the compiler is aware of (or
better yet, should not even exist...)

Rich