JamVM fails to build on a musl-based system due to a glibc-ism. Upstream already fixed this for uClibc by simply doing: #ifdef __UCLIBC__ return 0; However, musl doesn't have such a macro. The attached patch simply inverts the logic: #ifdef __GLIBC__ then do some funky stuff #else return NULL Reproducible: Always Steps to Reproduce: You have to first emerge gcc with USE="gcj" and gnu-classpath to be able to compile jamvm without having to build icedtea first. Then emerge jamvm.
Created attachment 387944 [details, diff] patch for non-glibc systems
I forgot to mention that jamvm need fpu_control.h. Putting the version from glibc (https://sourceware.org/git/?p=glibc.git;a=blob_plain;f=sysdeps/x86/fpu_control.h;hb=HEAD) into /usr/local/include allows it to compile even on musl. It's kinda ugly but it works ;-)
This is a bit piecemeal. Can you create a commit against the hardened-development overlay and I'll apply. 1. git clone git://git.overlays.gentoo.org/proj/hardened-dev.git 2. git checkout musl 3. (add the ebuild and patch etc. make sure the ebuild has rev version -r99. look at other ebuilds in that overlay for examples) 4. git add . 5. git commit -m "<cat>/<pkg>: fixed to buidl on musl" 6. git format-patch HEAD^ 7. attack to the bug.
Created attachment 395268 [details, diff] Replace fpu_control by fenv
Created attachment 395270 [details, diff] musl does not have get_nprocs I think that Philipp's patch is actually wrong. nativeStackBase() should work fine with musl. However nativeAvailableProcessors() does not. I however can't test a full build. So please test.
Created attachment 428544 [details, diff] patch against musl-overlay Anthony, I forgot to follow up on this over last years exams ;-) Thanks to Felix, this is his patch!
(In reply to Philipp Ammann from comment #6) > Created attachment 428544 [details, diff] [details, diff] > patch against musl-overlay > > Anthony, I forgot to follow up on this over last years exams ;-) > > Thanks to Felix, this is his patch! you forgot the metadata.xml file. i added it. also, you're adding the patch conditionally. it doesn't look like its upstreamable, but if it is, let's try to get it working on all libc's and get it upstream.
(In reply to Anthony Basile from comment #7) > also, you're adding the patch conditionally. it doesn't look like its > upstreamable, but if it is, let's try to get it working on all libc's and > get it upstream. Thats why i patch conditionally -- we don't need it on other libcs. I'll try it on glibc later. I'm not running any uclibc system atm.
(In reply to Philipp Ammann from comment #8) > (In reply to Anthony Basile from comment #7) > > also, you're adding the patch conditionally. it doesn't look like its > > upstreamable, but if it is, let's try to get it working on all libc's and > > get it upstream. > > Thats why i patch conditionally -- we don't need it on other libcs. I'll try > it on glibc later. I'm not running any uclibc system atm. those conditionals should then be brought into the package itself, not in the ebuild. eg. if one libc doesn't provide fucntion foo() but another does, then you should do AC_CHECK_FUNCS([foo]) in configure.ac and then use #ifdef HAVE_FOO ... #else ... #endif in the c code.
Created attachment 428728 [details, diff] jamvm-2.0.0-r99.ebuild: apply patch unconditionally Felix's patch works on glibc. I've renamed the patch since it's not really about musl but removes a glibc peculiarity.
(In reply to Philipp Ammann from comment #10) > Created attachment 428728 [details, diff] [details, diff] > jamvm-2.0.0-r99.ebuild: apply patch unconditionally > > Felix's patch works on glibc. I've renamed the patch since it's not really > about musl but removes a glibc peculiarity. that patch may be upstreamable.
I've just sent the patch to https://sourceforge.net/p/jamvm/patches/6/. However the project has not seen any commits since July 2014 and other patches sent to sourceforge seem to have been ignored for even longer. So I wouldn't expect this to land upstream (and upstream to make a new release) any soon. It would be nice if the patch could find its home in the main tree.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=2299174675e79b9c026e6e1c5020cc43b471a9f1 commit 2299174675e79b9c026e6e1c5020cc43b471a9f1 Author: Jakov Smolić <jsmolic@gentoo.org> AuthorDate: 2021-11-21 08:02:13 +0000 Commit: Jakov Smolić <jsmolic@gentoo.org> CommitDate: 2021-11-21 08:10:56 +0000 dev-java/jamvm: treeclean Closes: https://bugs.gentoo.org/527788 Closes: https://bugs.gentoo.org/736699 Closes: https://bugs.gentoo.org/645130 Signed-off-by: Jakov Smolić <jsmolic@gentoo.org> dev-java/jamvm/Manifest | 1 - .../jamvm/files/jamvm-2.0.0-classes-location.patch | 27 ----- dev-java/jamvm/files/jamvm-2.0.0-env.file | 15 --- dev-java/jamvm/files/jamvm-2.0.0-javac.in | 57 --------- dev-java/jamvm/files/jamvm-2.0.0-noexecstack.patch | 48 -------- dev-java/jamvm/jamvm-2.0.0-r1.ebuild | 131 --------------------- dev-java/jamvm/metadata.xml | 11 -- profiles/package.mask | 1 - 8 files changed, 291 deletions(-)
