There are multiple problems, I think, none of them caused by pike or the pike package definition.
The definition of the java “dependency” (a buildlink3 file in pkgsrc terminology) does not seem to have considered that someone might want to link the jvm into another program, so the necessary definition in that file that would allow the various include and library directories to be available in builds that depend on it didn’t exist. But it also doesn’t appear that adding that works properly.
Most of the masking behavior is implemented by the so called wrappers, which rewrite the command line arguments to, say, gcc, according to a configuration file generated by the package definition and all of its declared dependencies. In situation where lib or include files are in standard locations, those files are copied into a special location and all command line args that point to things like /usr/lib and /usr/include are rerouted. In other cases, directories or files are “whitelisted” as you mentioned, and the wrappers are instructed to pass those arguments through unchanged.
I had some patches that caused things to work in the past but they don’t seem to work any more. Luckily there’s a file containing all of the before/after tool executions so I can see what’s actually being run.
Things are currently at the point where at least some of the tests should succeed (such as detecting jni.h) based on the commands that are actually being run, but I haven’t narrowed it down further. I may spend a bit more time on this if I get a chance this weekend.
Example:
Here’s the entry in the config.log file for the Java module:
configure:7297: checking for jni.h configure:7297: result: no
And here’s the corresponding call to cc as well as what was actually run:
[*] cc -c -msave-args -I/opt/local/include -I/usr/include -I/opt/local/include -I/usr/include conftest.c -g
<.> /home/pbulk/build/wip/pike8.0-Java/work/.gcc/bin/gcc -I/opt/local/java/openjdk17/include -fcommon -m64 -fstack-protector-strong -D_FORTIFY_SOURCE=2 -c -msave-args -I/home/pbulk/build/wip/pike8.0-Java/work/.buildlink/include conftest.c -g -specs=/home/pbulk/build/wip/pike8.0-Java/work/.cwrapper/specs.pkgsrc -gdwarf-4 -gstrict-dwarf
The jni.h file is in /opt/local/java/openjdk17/include, so I would have expected that the test for it would have found it, yet it doesn’t. I might have to dig into the configure script to see what’s going on, but I think it’s using a custom test so maybe something there is going off in a wrong direction?
Thanks for your feedback. I think based on this output, those tests should be working, correct?
On Jul 2, 2026, at 4:36 AM, Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) @ Pike (-) developers forum 10353@lyskom.lysator.liu.se wrote:
So is the problem that the libraries/tools are not specified in the package definition, or that the wrapper prevents access to them anyway? In the latter case maybe it's some wrapper configuration, like some sort of whitelist, that is needed? (I'm not familiar with the wrapper in question, but I know for example Yocto's "pseudo" has such a mechanism.)
Could you perhaps provide some more detail about what fails how and when?