musl: fix weak_alias in projects expecting glibc behavior

[msabwat]

This patch fixes #14350, by adding a semicolon. The macro can be
used in both cases :

• weak_alias(fun, alias)
• weak_alias(fun, alias);

This is possible because calling (for eg.) :

extern __typeof(__memchr) memchr __attribute__((__weak__, __alias__("__memchr")));;

with two semicolons is valid, it won't break the current weak_alias(); calls in musl with the semicolon

[sbc100]

libc.h is an internal header that is only used when compiling musl.

It should be impossible to ever include this file except when compiling musl.. how are you including it?

[sbc100]

If could be that in some older version of emscripten is was possible to include this file... can you try with the latest version?

[msabwat]

If could be that in some older version of emscripten is was possible to include this file... can you try with the latest version?

I did, tested with 2.0.23

It should be impossible to ever include this file except when compiling musl.. how are you including it?

my bad, I think I patched the wrong file

emscripten/system/lib/libc/musl/include/features.h

Line 36 in 32dfcc9

#define weak_alias(old, new) \

[sbc100]

Ah yes, it looks like this issue was already fixed upstream in musl but splitting this into a public features.h and an internal one (the public one no longer contains this macro.

I've been working on a musl upgrade for a while not which would address this.

Where is this code being used downstream? Presumably downstream contains its own defintion of weak_alias guards with and #ifndef. Could you instead patch that code to do #undef weak_alias to avoid getting the musl version. This macro is not standard and musl should not really be defining it at all IIUC.

[sbc100]

Actually can you just try just removing that macro from features.h... it looks like it was added locally at some point and does not exist upstream at all.

[sbc100]

It looks like it was added in #11215

[sbc100]

I created a PR to remove it completely: #14379

[msabwat]

Ah yes, it looks like this issue was already fixed upstream in musl but splitting this into a public features.h and an internal one (the public one no longer contains this macro.

I've been working on a musl upgrade for a while not which would address this.

Where is this code being used downstream? Presumably downstream contains its own defintion of weak_alias guards with and #ifndef. Could you instead patch that code to do #undef weak_alias to avoid getting the musl version. This macro is not standard and musl should not really be defining it at all IIUC.

I don't think it's possible to undef it, I tried and it gets reincluded if, for example you include string.h (which will include features.h). But it does correctly handle the case where weak_alias is not defined at all. Thanks !

[msabwat]

I created a PR to remove it completely: #14379

Thank you very much Sam!