Failing tests on Alpine Linux #356
Comments
|
Alpine Linux is based on the musl library and GNUstep has not been tested much on that. it seems that there a big differences. As for this specific issue with NSCalendar it depends on whether your system provides libICU and if so in which version. If you want to improve support for musl based system this is great. We are ready to accept patches. |
|
I have the package
Although I am not experienced with Objective-C, like I said, I will see what I can do and report my progress here. I would very much like to see Alpine support GNUstep. By the way, I have observed that Void Linux (which has musl as an option) seems to use GCC instead of Clang. Update: The file Headers/GNUstepBase/GSConfig.h has Update 2: I have inserted a date = udat_parse (internal->_formatter, text, textLength, &pPos, &err);
NSLog(@"err = (%d)", err);
if (U_SUCCESS(err))
result =
[NSDate dateWithTimeIntervalSince1970: (NSTimeInterval)(date / 1000.0)];which gives in the file Tests/tests.log: The number 9 is associated with Update 3: It appears that the locale setting is to blame for failed date = [dateFormatter dateFromString:@"22 Nov 1969 08:15:00 Z"];Update 4: Calling |
|
With #357 applied (and the resultant Update/note: As a follow up on the Void Linux using GCC/vanilla libobjc instead of Clang/libobjc2, I tried recompiling under stock (the failed file is the same as for Clang/libobjc2, base/NSStream/socket.m). What's kind of important is that etc. |
|
Next failing test is from Update: Before that, Where "Грешка сегментације" means "Segmentation fault". Full tests.log attached. |
|
@Strahinja just for your information, I do run GNUstep on Alpine Linux. I fixed support for its musl platform in make some time ago. Best is that you use all compiled from source, use the gcc runtime and see if you replicate my environment. Later we can check if and how Alpine provides its packages. However, I am unable to run test on this 3.18 laptop. I have another run and will report back. |
|
I have a laptop with 3.17 Alpine and which was not updated since a while and there whole gnustep, including GUI work and GUi app runs. I remember having fixed things well enough. First, I update whole gnustep but not Alpine..I will report back. |
I recompiled everything using GCC/vanilla libobjc, and your advice ( With that, I was able to run gnustep-tests: The resulting tests.log is attached. I haven't applied here my fix for localized date tests, so those tests fail too. What is surprising to me is that there are more failing tests, in contrast to the previous results. The build system seems so fragile with all the numerous ways to set up the build environment. For example, on my other machine I use umask 027, and it messes with the installation process. /rant I was, however, able to compile, install and run
About Gorm, it compiles and installs fine, but when I run and so on. Update: It seems that libGormObjCHeaderParser.so.0.0.1 is installed with the incorrect ownership (regular user!). Other libraries seem installed like that as well, for example libgnustep-base.so.1.29.0, libgnustep-gui.so.0.30.0, libInterfaceBuilder.so.1.1.0 etc. So I did still, libGormCore.so.0.0.1 is the only one with relocation problems. Suggestion: Perhaps use the standard utility install to install files with the correct ownership and permissions? |
|
Terminal does not have images in its preference bar. So it is fine as you see it. on 3.18 Alpine, I stop at the build of gui with mysterious shell errors. |
|
I'll try to set up a "clean", default Alpine environment in an emulator and check if there any Busybox-related issues not present on my mksh-using system later. I'll report what I find out here. |
|
Using GCC/vanilla libobjc (packages
My observations:
|
|
On 6 Dec 2023, at 18:27, Страхиња Радић ***@***.***> wrote:
I noticed things like:
Making install for framework GormCore...
(cd .; \
tar cfX - /usr/local/share/GNUstep/Makefiles/tar-exclude-list \
GormCore.framework) \
| (cd /usr/local/lib/GNUstep/Frameworks; tar xf -)
(using tar to install files?!)
Then, all the install commands are using arguments similar to:
/usr/bin/install -c -p -m 644 GormViewEditor.h GormCore.framework/Versions/0/Headers/GormViewEditor.h
this command doesn't set ownership. When I use a command like:
$ touch test.file
$ doas /usr/bin/install -c -p -m 644 test.file /usr/include/test.file
$ ls -l /usr/include/test.file
-rw-r--r-- 1 strajder strajder 0 Dec 6 19:11 /usr/include/test.file
whereas the following explicit form works:
$ doas /usr/bin/install -c -p -m 644 -o root -g root test.file /usr/include/test.file
$ ls -l /usr/include/test.file
-rw-r--r-- 1 root root 0 Dec 6 19:11 /usr/include/test.file
so the fix for the incorrect ownership set by GNUstep make would be to add -o root and -g root to all invocations of install.
There's no fix, because there's nothing wrong: the correct owner to install stuff as (when doing a build from source) is normally the user doing the installing.
When you build and install from source you are normally building a private/personal copy of the system, which is quite different from installing a package.
That being said, gnustep-make does support installing as a non-standard user/group ...
When you want to install stuff as a different user, you can specify the user by defining INSTALL_AS_USER=xxx before running make.
If you are doing that, you would usually also want to define INSTALL_AS_GROUP=xxx to install with a non-standard group too.
|
|
NB. The INSTALL_AS_USER and INSTALL_AS_GROUP settings may also be used *inside* a make file.
That's for cases where you (as developer of some software) know that you want to have it installed as a particular user, or where you want to set a default user to have it installed as.
|
Perhaps it is semantics. To be precise, on Busybox systems using OpenDoas the installation of programs compiled from source, by GNUstep make, isn't applying correct ownership - that's unexpected/undesired. From the above simple test I made, it seems that, in contrast with GNU install and/or sudo, with Busybox' install and/or OpenDoas that isn't the case: the user and group aren't changed.
Than that is the fix for the above unexpected behavior. Thanks. |
|
We have something interesting here between A.pine 3.17 and Alpine 3.18. I have two laptops with 3.17. Both build and install fine up to standard user applications, including Gorm, which runs fine. As an example, my R40 has: make: base:
I can't run tests because of these errors: |
Yes, this happens because the gnustep-tests script is assuming GNU Bash (thus Bash should be mentioned as a hard requirement, at least for using those scripts, unless the scripts are rewritten to support other shells - POSIX sh compatibility should be sufficient). The shebang is and check again if it works? |
I just checked on 3.18, I have bash installed, /bin/bash exists, yet I can't run make check. |
|
Update on 3.18 status, compared to my previous attempts, I am able to compile base, gui and back. No longer strange issues. I cannot run tests as on 3.17. However I am unable to run GUI apps, I get this issue: |
This sounds as if the script is somehow (alias? Makefile?) forcibly run through non-Bash shell. For example: Or, Bash might silently accept non-POSIX functionality if /bin/sh is a link to /bin/bash, and the build system is relying on that nonstandard behavior. If the script is already assuming Bash, it might be better to replace the (hypothetical) |
|
On 11 Dec 2023, at 16:22, Riccardo ***@***.***> wrote:
# apk add bash
and check again if it works?
I just checked on 3.18, I have bash installed, /bin/bash exists, yet I can't run make check.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you commented.Message ID: ***@***.***>
I think this may be a bug in the gnustep-make configure script.
It looks like it tries to find bash, but falls back to /bin/sh
Please try reconfiguring/reinstalling gnustep-make now that you have bash installed.
If that fixes it, we can figure out how best to fix the configure script to abort or to warn if bash is not found.
|
You are right, I had to be more convincing when configuring... Did a clean configure, installed and it worked. I will retry on 3.17 too. Now tests results are: base/NSNumberFormatter/basic10_4.m: |
This might have a similar cause to the bug with formatting dates: the tests are expecting English locale settings, while not explicitly setting English locale, and are done with the non-English locale settings in the environment. Can you try rerunning tests after setting |
I have LANG set to C.UTF-8 and LC_ALL empty. |
|
with Richard yesterday we worked on a check for bash - it is non-requiredso non-developers can continue without. However on run of a test an explicative error is shown. The test-suite has a hard-requirement on bash. |
|
I am able to build and run apps on Apline 3.18. Thus I took the time to upgrade one of my two 3.17 systems to 3.18, rebuilt gnustep and all runs fine, including backend, I was missing libXmu dev files and due to internal headers, this causes some strange things in back. Solved. So the core of the original point remains: some tests failing for locale and similar. |
|
@rmottola I found out what is most likely executing /bin/sh - it is make itself. The GNU make documentation states that if the shell is not set in the variable To summarize, there are multiple issues (I'm not sure if I should open separate "issues" here on Github for them). I think that this particular Bash-related issue happens when /bin/sh is not a link to /bin/bash. (At least it seems to on your system, I haven't experienced it myself. In the freshly installed Alpine 3.18 in the emulator, with installed GNU Bash in /bin/bash and /bin/sh being a link to /bin/busybox, the |
I'm trying to get GNUstep working on Alpine Linux v3.18. Currently,
libs-guican't compile on my system, so I was instructed to checklibs-basefirst.The first thing I did was run
doas make uninstallin every component built so far, uninstallgcc-objc,libobjcandg++. I then builttools-make,libobjc2, then rebuilttools-makewithmake clean, then running the old make script again:before proceeding to build
libs-baseand rungmake check(I figured out that GNUstep make needs to be called as gmake on my own). UPDATE: This depends on whether the packagemakefrom theedgeorv3.18branch is used. The version fromedgehas /usr/bin/gmake along with /usr/bin/make, while the version fromv3.18doesn't -- it has only /usr/bin/make.This was the summary of tests:
The first issue was GNUTLS, which failed tests until I changed the path to certtool to be the absolute one.
Like that, I have the following results of
gmake check:(I have no idea how the number of passed tests is smaller, I am building on my desktop and laptop separately, and I copied the previous results from my comment a couple of days back, so that might explain it.)
UPDATE: The issue with GNUTLS seems to have resolved itself somehow (?) (reverting the patch, doing
make clean, rebuilding and runningmake checkdoesn't make the GNUTLS tests fail), so no patch is needed for that.The first failed check out of the rest was about
NSCalendar. By inserting the call toNSLogI was able to print out the obtained date components:they are:
What can be done here to investigate this further? I don't have experience with Objective-C.
The text was updated successfully, but these errors were encountered: