Problems with libc6-compat

Problems with libc6-compat

[Augusto César Dias]

[-- Attachment #1: Type: text/plain, Size: 1437 bytes --]

Hello,

I'm trying to run my rust application on Alpine but I'm having problems
with either using musl as a target or using the compatibility layer for
glibc.

When I try to use from the libc6-compat I'm having this problem:


Error relocating my_app: __register_atfork: symbol not found
Error relocating my_app: __res_init: symbol not found


Is this a bug or this symbols are not at all supported by the compatibility
layer?


When I try to target musl, I have a different problem. I cannot compile my
application directly on musl, because some features from the rust compiler
are not supported. What I did was compiling on a debian image targeting
musl and moving my binary to my alpine image. It looks like even targeting
musl, the linker still uses some glibc variants at build time, which my
little experience with C doesn't help me being sure if this would be a
problem or not.

My application depends on glib2 which I installed through apk and when it
starts it fails with the following:

**
GLib-GObject:ERROR:../gobject/gtype.c:2743:g_type_register_static:
assertion failed: (static_quark_type_flags)
Aborted


I've trying to compile a C example directly in my alpine container and it
works in there, so that made me believe I'm having some problems with the
cross compilation/linking in my glibc container.

Any ideas on how can I solve this?


Best regards,

*Augusto César Dias*

[-- Attachment #2: Type: text/html, Size: 3063 bytes --]

Re: Problems with libc6-compat

[Szabolcs Nagy]

* Augusto César Dias <augusto.c.dias@gmail.com> [2019-11-08 13:26:33 +0100]:
> My application depends on glib2 which I installed through apk and when it
> starts it fails with the following:
> 
> **
> GLib-GObject:ERROR:../gobject/gtype.c:2743:g_type_register_static:
> assertion failed: (static_quark_type_flags)
> Aborted

there is at least one known glibc quark bug
https://gitlab.alpinelinux.org/alpine/aports/blob/master/main/glib/0001-gquark-fix-initialization-with-c-constructors.patch

but that should be fixed in alpine, and in recent musl
it should work even without patching, unless this is
static linking.

> I've trying to compile a C example directly in my alpine container and it
> works in there, so that made me believe I'm having some problems with the
> cross compilation/linking in my glibc container.
> 
> Any ideas on how can I solve this?

why do you need to cross compile?

building natively on a musl based distro where all dependencies
are correctly built and packaged should be much more reliable.

Re: Problems with libc6-compat

[Augusto César Dias]

[-- Attachment #1: Type: text/plain, Size: 1317 bytes --]

It is indeed. The problem is there are some features in the rust compiler
that are not supported in musl.


*Augusto César Dias*


On Fri, Nov 8, 2019 at 2:15 PM Szabolcs Nagy <nsz@port70.net> wrote:

> * Augusto César Dias <augusto.c.dias@gmail.com> [2019-11-08 13:26:33
> +0100]:
> > My application depends on glib2 which I installed through apk and when it
> > starts it fails with the following:
> >
> > **
> > GLib-GObject:ERROR:../gobject/gtype.c:2743:g_type_register_static:
> > assertion failed: (static_quark_type_flags)
> > Aborted
>
> there is at least one known glibc quark bug
>
> https://gitlab.alpinelinux.org/alpine/aports/blob/master/main/glib/0001-gquark-fix-initialization-with-c-constructors.patch
>
> but that should be fixed in alpine, and in recent musl
> it should work even without patching, unless this is
> static linking.
>
> > I've trying to compile a C example directly in my alpine container and it
> > works in there, so that made me believe I'm having some problems with the
> > cross compilation/linking in my glibc container.
> >
> > Any ideas on how can I solve this?
>
> why do you need to cross compile?
>
> building natively on a musl based distro where all dependencies
> are correctly built and packaged should be much more reliable.
>

[-- Attachment #2: Type: text/html, Size: 2431 bytes --]

Re: Problems with libc6-compat

[Rich Felker]

On Fri, Nov 08, 2019 at 02:18:26PM +0100, Augusto César Dias wrote:
> It is indeed. The problem is there are some features in the rust compiler
> that are not supported in musl.

Could you elaborate on that? My understanding is that several
musl-based distros are shipping rustc and it's believed/expected to
work fine, but maybe I'm missing something.

Rich


> On Fri, Nov 8, 2019 at 2:15 PM Szabolcs Nagy <nsz@port70.net> wrote:
> 
> > * Augusto César Dias <augusto.c.dias@gmail.com> [2019-11-08 13:26:33
> > +0100]:
> > > My application depends on glib2 which I installed through apk and when it
> > > starts it fails with the following:
> > >
> > > **
> > > GLib-GObject:ERROR:../gobject/gtype.c:2743:g_type_register_static:
> > > assertion failed: (static_quark_type_flags)
> > > Aborted
> >
> > there is at least one known glibc quark bug
> >
> > https://gitlab.alpinelinux.org/alpine/aports/blob/master/main/glib/0001-gquark-fix-initialization-with-c-constructors.patch
> >
> > but that should be fixed in alpine, and in recent musl
> > it should work even without patching, unless this is
> > static linking.
> >
> > > I've trying to compile a C example directly in my alpine container and it
> > > works in there, so that made me believe I'm having some problems with the
> > > cross compilation/linking in my glibc container.
> > >
> > > Any ideas on how can I solve this?
> >
> > why do you need to cross compile?
> >
> > building natively on a musl based distro where all dependencies
> > are correctly built and packaged should be much more reliable.
> >

Re: Problems with libc6-compat

[Augusto César Dias]

[-- Attachment #1: Type: text/plain, Size: 2036 bytes --]

Yes, even rust has an official alpine image to compile rust applications on it, but it states some features won’t work such as procedural macros which some libraries makes use of. Here’s an issue stating what should be done...

https://github.com/rust-lang/rust/issues/40174#issuecomment-538791091

Augusto

https://github.com/rust-lang/rust/issues/40174#issuecomment-538791091

>>> On 8. Nov 2019, at 18:47, Rich Felker <dalias@libc.org> wrote:
>> On Fri, Nov 08, 2019 at 02:18:26PM +0100, Augusto César Dias wrote:
>> It is indeed. The problem is there are some features in the rust compiler
>> that are not supported in musl.
> 
> Could you elaborate on that? My understanding is that several
> musl-based distros are shipping rustc and it's believed/expected to
> work fine, but maybe I'm missing something.
> 
> Rich
> 
> 
>>>> On Fri, Nov 8, 2019 at 2:15 PM Szabolcs Nagy <nsz@port70.net> wrote:
>>> * Augusto César Dias <augusto.c.dias@gmail.com> [2019-11-08 13:26:33
>>> +0100]:
>>>> My application depends on glib2 which I installed through apk and when it
>>>> starts it fails with the following:
>>>> **
>>>> GLib-GObject:ERROR:../gobject/gtype.c:2743:g_type_register_static:
>>>> assertion failed: (static_quark_type_flags)
>>>> Aborted
>>> there is at least one known glibc quark bug
>>> https://gitlab.alpinelinux.org/alpine/aports/blob/master/main/glib/0001-gquark-fix-initialization-with-c-constructors.patch
>>> but that should be fixed in alpine, and in recent musl
>>> it should work even without patching, unless this is
>>> static linking.
>>>> I've trying to compile a C example directly in my alpine container and it
>>>> works in there, so that made me believe I'm having some problems with the
>>>> cross compilation/linking in my glibc container.
>>>> Any ideas on how can I solve this?
>>> why do you need to cross compile?
>>> building natively on a musl based distro where all dependencies
>>> are correctly built and packaged should be much more reliable.

[-- Attachment #2: Type: text/html, Size: 6527 bytes --]

Re: Problems with libc6-compat

[Johannes Brechtmann]

On Fri, 8 Nov 2019 19:57:24 +0100
Augusto César Dias <augusto.c.dias@gmail.com> wrote:

> Yes, even rust has an official alpine image to compile rust
> applications on it, but it states some features won’t work such as
> procedural macros which some libraries makes use of. Here’s an issue
> stating what should be done...
> 
> https://github.com/rust-lang/rust/issues/40174#issuecomment-538791091

Procedural macros are not restricted by musl but by static linking,
which rustc defaults to for musl targets. Enforcing dynamic linking
enables you to use procedural macros on musl:

https://github.com/rust-lang/rust/pull/58575#issuecomment-496026747


Johannes

Re: Problems with libc6-compat

[Augusto César Dias]

[-- Attachment #1: Type: text/plain, Size: 939 bytes --]

Oh my god.

Thank you very much. It does works and everything is running smoothly now :)


Best regards,

*Augusto César Dias*


On Fri, Nov 8, 2019 at 10:08 PM Johannes Brechtmann <johannes@jnbr.me>
wrote:

> On Fri, 8 Nov 2019 19:57:24 +0100
> Augusto César Dias <augusto.c.dias@gmail.com> wrote:
>
> > Yes, even rust has an official alpine image to compile rust
> > applications on it, but it states some features won’t work such as
> > procedural macros which some libraries makes use of. Here’s an issue
> > stating what should be done...
> >
> > https://github.com/rust-lang/rust/issues/40174#issuecomment-538791091
>
> Procedural macros are not restricted by musl but by static linking,
> which rustc defaults to for musl targets. Enforcing dynamic linking
> enables you to use procedural macros on musl:
>
> https://github.com/rust-lang/rust/pull/58575#issuecomment-496026747
>
>
> Johannes
>

[-- Attachment #2: Type: text/html, Size: 2208 bytes --]

Re: Problems with libc6-compat

[A. Wilcox]

[-- Attachment #1.1: Type: text/plain, Size: 597 bytes --]

Can you try building your crate on Adélie Linux?  We've specifically
enabled dynamic linking in rustc for musl libc, which should provide you
these features.

Let me know.  If it does work, then this should probably be noted in one
of the issue trackers for Rust.

Additionally, our 'gcompat' package should provide both of your missing
symbol:

libgcompat/pthread.c:28:int __register_atfork

__res_init should be provided by musl, I thought, but we can add an
alias if needed.

Best,
--arw

-- 
A. Wilcox (awilfox)
Project Lead, Adélie Linux
https://www.adelielinux.org


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]