typelevel
scala-native 0.5.9
Stacktraces broke at least on ARM Linux (scala-native; 2.13 and 3); 2 examples:
- https://github.com/typelevel/cats-effect/actions/runs/18574362636/job/52958750712#step:22:1975
- https://github.com/typelevel/cats-effect/actions/runs/18574362636/job/52956834671#step:22:3670
You should be able to just do the following:
https://github.com/scala-native/scala-native/blob/3f89e6f4ad8b657d5475dbaec65dca437168ae1e/javalib/src/main/resources/scala-native/scala-native.properties
Or conversely like this:
https://github.com/scala-native/scala-native/pull/4523/files
Thank you for this PR. You know the CE build environment and there are plenty of log files. I would have gotten lost.
The code in https://github.com/scala-native/scala-native/pull/4523/files Eric linked above
should give you exactly what CE had with SN 0.5.8 and before.
By my understanding "-std=c11" gives one standard C ISO C.
Defining "_POSIX_SOURCE" adds various elements marked by the Open Group (a.k.a POSIX) as extensions to ISO C.
Defining "_GNU_SOURCE" adds more magic to the soup.
Starting from a clean sheet of paper, "_POSIX_SOURCE" is preferable to most/many/well_a_few people. It is well documented, the documentation is readily available and the extensions are, for the most part, reasonable. It is also more likely to port to "unix-like" but not strictly unix systems. That is, other POSIX compliant or near compliant systems. Of course, here we are talking about signals, so all bets are off to begin with.
In this case, we are dealing with existing code which used, effectively, _GNU_SOURCE. I believe there are some slight differences in how some things are defined. This is Fear, Uncertainty, & Doubt and a wish to get to dinner before midnight. If I were betting my paycheck or tranquility over the next few weeks, I hold my nose, honor existing practice (stare decisis) and go with _GNU_SOURCE. Of course, that is announcing to the world that I have few scruples when maintaining code.
(I compared the file using -std=11, _POSIX_SOURCE, and _GNU_SOURCE using the clang/gcc -E option to run just the pre-processor. I did not look at the slight differences between the latter two.)
Let me know if & how I can help.
Do you think the errors in the log file have to do with 0.5.9 or with _Mumble_SOURCE?
If the former, I will give things a closer look. I took a fast run thru the logs and could not make sense of them, limitation at my end.
Do you think the errors in the log file have to do with 0.5.9 or with _Mumble_SOURCE?
Which errors, in which log file?
Stacktraces broke at least on ARM Linux (scala-native; 2.13 and 3); 2 examples:
* https://github.com/typelevel/cats-effect/actions/runs/18574362636/job/52958750712#step:22:1975 * https://github.com/typelevel/cats-effect/actions/runs/18574362636/job/52956834671#step:22:3670
Yes, there were some stack trace changes in 0.5.9. I believe that they had to do with "lazy loading".
I do not want to be spreading falsehoods do to my not being up to date, but I thought stack traces were broken in ARM Linux for a very long time. Perhaps different breakage.
I looked at one of the cited log file and did not see a stack trace where the log said there was a failure. I do not read CE, sorry, so what was the failure? Do you have any idea?
You might try again with _GNU_SOURCE to see if anything improves. I suspect you are seeing an unrelated & real problem.
Yeah, I'm looking at https://github.com/scala-native/scala-native/pull/4512, it seems possibly related. Some of our unittests fail at least on ARM Linux. All the failing tests depend on getting stacktraces. These same tests passed on ARM Linux with SN 0.5.8. I do not know yet the exact nature of the failures.
A suggestion following up on a suggestion by @ekrich in CE Issue #4509.
#define _POSIX_C_SOURCE 202405L // Open Group 2024 Issue 8
The stacktrace thing is this: https://github.com/scala-native/scala-native/issues/4526.
The stacktrace thing is this: https://github.com/scala-native/scala-native/issues/4526.
Thank you for the SN Issue. Wojciech will see the discussion there.
Do you happen to know what happens if you toggle .generateFunctionSourcePositions(false)
back to true? Still SEGFAULT? Not trying to suck you down into a days long rat hole.
e40493b seemed to do the trick & move in a desired direction to boot.
I think I found the SN NullPointerException which was killing skunk (I think that is another CE project).
As always, yell if SN is misbehaving for CE. I may not be able to fix it, but I can listen & investigate.
Do you think the errors in the log file have to do with 0.5.9 or with _Mumble_SOURCE?
Which errors, in which log file?
Overcome by events, logs for current commit are all green.
s5bug:
I like block you suggested about incompatible prior POSIX/Open_Group versions being specified. Thank you, I'll have to remember it.
#if defined(_POSIX_C_SOURCE)
#if _POSIX_C_SOURCE < 123456L
#error ...
#endif
#else
#define _POSIX_C_SOURCE 123456L
#endif
People can and do specify POSIX versions outside the compilation unit: say on the command line by a build file. I do not want to take on the responsibility for telling them that they are wrong for using a time honored practice.
IMO, the basic problem is a project shipping files which have to be compiled outside of a known environment, say CI. There are just too many variants and time honored practices for a small devo team to reliably cover. For the while, it is probably easier to achieve than using Dockerfiles or shipping os specific archive (.a) or libraries (.so). I can still grumble about the development cost of "glue" files and use them if I must.
Hope all your coding is going well.