[gentoo-soc] Week 9 Report for Musl support expansion to support GNOME desktop

[listout]

Hello there folks, hope you are doing well.

With the end of week 9 I'm here with the weekly report on on musl
support expansion for GNOME desktop. For this week I've fixed a few bugs
for my mentor, Sam. These bugs were in software that he uses personally
and I'm happy that I was able to fix them in minimal time. I'll talk
about the bugs and fixes a little bit more in detail later, but other
than that I've also managed to build blender on musl profile, will too
I'll discuss later it the report.

The bugs that Sam requested to me look into were in folly and watchman,
respectively. Both for these programs come from Facebook. For the
package folly, it was expecting a define, `__ELF_NATIVE_CLASS`, on
systems other than FreeBSD, the `__ELF_NATIVE_CLASS` is also used to
define another `FOLLY_ELF_NATIVE_CLASS`. But unfortunately on musl it
was not the case, and as a result `FOLLY_ELF_NATIVE_CLASS` was not
being defined. Hence, instead of relying on FreeBSD and LP64, we now
only check for LP64 and define `FOLLY_ELF_NATIVE_CLASS`. This was
initially proposed on a relevant github issue [1], and my PR can be
found here [2].


For watchman, the developers used `__fswort_t` as a type for a variable
but unfortunately this is an internal glibc type and cannot be used on
other libc's. Hence following the advice from Linux manpages and Richard
<dalias> on IRC, I changed the type to `unsigned long`. Since `unsigned
long` is available on all most all libc's we wouldn't have any problems
on future. My conclusion on using `unsigned long` instead of `unsigned
int` like Linux manpages stated was due to `__fswort_t` itself being on
long type [3] and you can find my PR over here [4].

Last but not the least, blender. However, before going into blender, I
had to fix one on blender's dependencies named opencolorio [5].
opencolorio seemed to be using a function `::strtol_l`. I'm not at all
familiar with the uses of this particular function. The compiler issues
a suggestion of using `::strtol` instead of `::strtol_l` and after a bit
of googling I happen to come across Alpine Linux's patch [6] for this
and they too used `::strtol`. Therefore I choose to use the `::strtol`
function wrapped around a `ifdef __GLIBC__`. I took Alpine Linux's patch
in as is manner, hence not providing the like to PR.

For blender, it required a little bit patching, four to be exact. I'll
try by best to explain most of them. I'll start with the most simple
patch of these four. In the file *intern/libc_compat/libc_compat.c* the
developers wanted to check if a certain version of glibc was present
before going further. On non glibc systems, the macro used to check the
version (`__GLIBC_PREREQ(2, 31)`) caused a build error. Hence I though
it would be appropriate to first check for the existence of glibc, with
the status of definition of macro `__GLIBC_PREREQ` before checking the
glibc version. I actually came up with this version of the patch with
the help from a person on blender.chat.

For the next three patches, it were almost same. Don't use the
header/functions is they are not available with current libc. For this I
use the Cmake build systems `CHECK_SYMBOL_EXISTS` and
`CHECK_INCLUDE_FILES`. Other Linux distributions like Void and Alpine
were already using a version of these patches, just that they are not
generalist in nature and not suitable for sending upstream. You can
actually see what I've done here [7].

I'm trying to send all of these patches upstream, lets hope for the
best. That will it for this weeks report, hope to bring you more next
week (unfortunately not much week of GSoC is left).

[1]: https://github.com/facebook/folly/issues/1478#issuecomment-719883898
[2]: https://github.com/gentoo/gentoo/pull/26807
[3]: https://code.woboq.org/qt5/include/bits/typesizes.h.html#46
[4]: https://github.com/gentoo/gentoo/pull/26850
[5]: https://opencolorio.org/
[6]: https://github.com/gentoo/gentoo/pull/26855
[7]: https://github.com/gentoo/gentoo/pull/26860
--
Regards,
listout