I didn’t clearly provide the linkage to the previous message I referred to: problem isn't related to pike directly, but rather to the way that pkgsrc works. Pkgsrc generates tool wrappers that ensure that only headers/libraries/tools that are specified in the package definition are available to the build tools. This mechanism causes problems with the configure scripts finding the dependencies needed to compile the module. This has impacted the Java module repeatedly over the years and if no one is using it in general, it doesn’t make sense for me to spend additional hours getting it to work. It does compile just fine on its own outside the confines of the pkgsrc build environment.

Bill

On Jul 1, 2026, at 11:14 PM, Martin Bähr mbaehr+pike@realss.com wrote:

Excerpts from H. William Welliver's message of 2026-07-01 22:26:37 -0400:

...

I’m wondering if there are folks that commonly use this module and thus it is something I should try to sort out, or if I should just tell anyone who asks to “compile it yourself”. I can confirm that a “pike -x module” in the Java module directory builds just fine if JAVA_HOME is set, so the problem is mostly about being able to provide a binary package of the Java support. Happy to hear feedback on the subject either way.

i am using (or building, if i have to) binary packages of pike with java support for my client so i'd appreciate it that worked. but i also don't remember any problems building the binary installer with java from pike 8.0.1956 git source so i am wondering why you are running into a problem. is it architecture specific? i am using amazonlinux-2023

greetings, martin.

looking for projects or part-time work: fullstack web development and general software development react aurelia angular | django laravel | js ts python php ruby pike go | git -- developer mentor mitzkits.co.tz roxen/pike specialist aeronetsoftware.com Martin Bähr working in tanzania http://codingforafrica.at

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?