Why are we compiling a minimal version of libssp at 007-Musl instead of just using GCC's?

[takusuman]

Reference:
https://git.alpinelinux.org/aports/tree/main/musl/APKBUILD#n53
https://github.com/dslm4515/Musl-LFS/blob/stable-9.00/doc/3-Chroot/007-Musl#L27-L30

[dslm4515]

Good question... I am not sure why, to be honest

I just copied over patches and APKBUILD from Alpine Linux and didn't evaluate each one... just to get GCC to build and work under musl. I would think by now, GCC would build under musl without patches.

I admit I didn't investigate why a minimal libssp was build instead of just using GCC's. I haven't gotten around testing GCC's libssp over the minimal one.

[dslm4515]

Looking at the APKBUILD for GCC for Alpine Linux, it doesnt say why:

# alpine musl provides libssp_nonshared.a, so we don't need libssp either

And APKBUILD for musl:

# provide minimal libssp_nonshared.a so we don't need libssp from gcc

[dslm4515]

Perhaps this explains it?

gcc did not do the right thing instead it has a (broken) libssp
implementation ...
so gcc allows the libc to implement ssp, but then it requires
the libc to provide the loccal symbol too which is not possible
(in case of dynamic linking). ..and it is a gcc internal target
specific optimization thing so it does not make sense to do this
in the libc even if it is possible.

what glibc does: the libc.so visible to ld is a linker script that
magically adds glibc's libssp_nonshared.a to the link command.
(and they build gcc with disabled libssp)
(of course this linker script can cause horrible pains and misery)

what musl does: implements the public api in libc.so, but requires
the compiler to provide the local definition. So e.g. you can build
gcc with libssp enabled which has libssp_nonshared.a or you can
provide one yourself.. but gcc does not add -lssp_nonshared if it
thinks the libc provides ssp, so that's why those patches are
needed: they add -lssp_nonshared back. (providing this lib yourself
is better since that avoids uselessly building and installing the
rest of libssp which can cause trouble if somebody accidentally
uses -lssp explicitly)

source

[takusuman]

Perhaps this explains it?

gcc did not do the right thing instead it has a (broken) libssp
implementation ...
so gcc allows the libc to implement ssp, but then it requires
the libc to provide the loccal symbol too which is not possible
(in case of dynamic linking). ..and it is a gcc internal target
specific optimization thing so it does not make sense to do this
in the libc even if it is possible.

what glibc does: the libc.so visible to ld is a linker script that
magically adds glibc's libssp_nonshared.a to the link command.
(and they build gcc with disabled libssp)
(of course this linker script can cause horrible pains and misery)

what musl does: implements the public api in libc.so, but requires
the compiler to provide the local definition. So e.g. you can build
gcc with libssp enabled which has libssp_nonshared.a or you can
provide one yourself.. but gcc does not add -lssp_nonshared if it
thinks the libc provides ssp, so that's why those patches are
needed: they add -lssp_nonshared back. (providing this lib yourself
is better since that avoids uselessly building and installing the
rest of libssp which can cause trouble if somebody accidentally
uses -lssp explicitly)

source

I think this explains pretty well, thanks a lot.

[dslm4515]

I do really appreciate the questions. Sometimes I forget about the little details when I first struggled to get this project working!

I was wondering too every time I build MLFS... lol, but always forgot to investigate!

[takusuman]

I do really appreciate the questions. Sometimes I forget about the little details when I first struggled to get this project working!

I was wondering too every time I build MLFS... lol, but always forgot to investigate!

I'm investigating MLFS since 2021 for building Copacabana Linux and, as a result, I've been also writing a lot of documentation.
May it can be a source/reference for some questions about MLFS' building process in the future (currently I'm still writing about it and it's only in portuguese yet).

[takusuman]

I do really appreciate the questions. Sometimes I forget about the little details when I first struggled to get this project working!
I was wondering too every time I build MLFS... lol, but always forgot to investigate!

I'm investigating MLFS since 2021 for building Copacabana Linux and, as a result, I've been also writing a lot of documentation. May it can be a source/reference for some questions about MLFS' building process in the future (currently I'm still writing about it and it's only in portuguese yet).

There's also a lot of research in other sites, such as books, articles etc.