Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 527788 - dev-java/jamvm fails to build with sys-libs/musl
Summary: dev-java/jamvm fails to build with sys-libs/musl
Status: IN_PROGRESS
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: [OLD] Java (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: Java team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: musl-porting
  Show dependency tree
 
Reported: 2014-11-01 11:19 UTC by Philipp Ammann
Modified: 2016-03-22 16:33 UTC (History)
3 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
patch for non-glibc systems (jamvm-non-glibc.patch,521 bytes, patch)
2014-11-01 11:19 UTC, Philipp Ammann
Details | Diff
Replace fpu_control by fenv (fpu_control.patch,1.78 KB, patch)
2015-01-31 22:11 UTC, Felix Janda
Details | Diff
musl does not have get_nprocs (nprocs.patch,317 bytes, patch)
2015-01-31 22:15 UTC, Felix Janda
Details | Diff
patch against musl-overlay (0001-dev-java-jamvm-fix-build-on-musl.patch,15.85 KB, patch)
2016-03-18 17:15 UTC, Philipp Ammann
Details | Diff
jamvm-2.0.0-r99.ebuild: apply patch unconditionally (0001-dev-java-jamvm-apply-fenv-patch-unconditionally.patch,9.11 KB, patch)
2016-03-21 20:37 UTC, Philipp Ammann
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Philipp Ammann 2014-11-01 11:19:08 UTC
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.
Comment 1 Philipp Ammann 2014-11-01 11:19:40 UTC
Created attachment 387944 [details, diff]
patch for non-glibc systems
Comment 2 Philipp Ammann 2014-11-01 11:40:46 UTC
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 ;-)
Comment 3 Anthony Basile gentoo-dev 2015-01-31 21:05:31 UTC
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.
Comment 4 Felix Janda 2015-01-31 22:11:57 UTC
Created attachment 395268 [details, diff]
Replace fpu_control by fenv
Comment 5 Felix Janda 2015-01-31 22:15:54 UTC
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.
Comment 6 Philipp Ammann 2016-03-18 17:15:07 UTC
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!
Comment 7 Anthony Basile gentoo-dev 2016-03-18 17:23:43 UTC
(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.
Comment 8 Philipp Ammann 2016-03-18 17:36:10 UTC
(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.
Comment 9 Anthony Basile gentoo-dev 2016-03-18 17:45:49 UTC
(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.
Comment 10 Philipp Ammann 2016-03-21 20:37:49 UTC
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.
Comment 11 Anthony Basile gentoo-dev 2016-03-22 08:06:27 UTC
(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.
Comment 12 Felix Janda 2016-03-22 16:33:21 UTC
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.