jBase (Windows) 6.2.1.1 JELF Errors

[Eric Karmark]

Veteran MV dev here looking to have a nostalgic tinker with MV systems - I've loaded up the latest eval version of jBASE on Windows 11, created a BP file as UD type and have done many rounds of working with Gemini and CoPilot on trying to solve an error in compiling programs as I keep getting the error below:

jsh eric ~ -->BASIC BP TEST
TEST
Source file TEST compiled successfully
jsh eric ~ -->CATALOG BP TEST
TEST
Object TEST cataloged successfully
jsh eric ~ -->RUN BP TEST
RUN: Unable to find JELF status on file TEST.dll
TEST: No such file or directory
jsh eric ~ -->

Tried dozens of config changes and reloaded jBase and Visual Studio multiple times but always get the "RUN: Unable to find JELF status on file " and program won't run. Running just 'TEST' at the command prompt works fine. I realise RUN is considered 'old practice' on jBase but that doesn't explain this issue - I'm wondering if this particular release has a bug that only presents on fresh jBase installs (versus upgrades) due to environment vars being wrong for new defaults (I suspect not too many folks are creating 'greenfield' jBASE installs these days). On a side note, I loaded the Ubuntu version and it works fine so I have a working system but now with the Windows install I'd love to find the fix 'just because its broken' - any thoughts/helps on this greatly appreciated!

Eric

[bdeck...@gmail.com]

What are the results of jshow -c TEST   ?

Sent from my iPhone

On Apr 17, 2026, at 3:32 PM, Eric Karmark <ekar...@gmail.com> wrote:

Veteran MV dev here looking to have a nostalgic tinker with MV systems - I've loaded up the latest eval version of jBASE on Windows 11, created a BP file as UD type and have done many rounds of working with Gemini and CoPilot on trying to solve an error in compiling programs as I keep getting the error below:

--
You received this message because you are subscribed to
the "Pick and MultiValue Databases" group.
To post, email to: mvd...@googlegroups.com
To unsubscribe, email to: mvdbms+un...@googlegroups.com
For more options, visit http://groups.google.com/group/mvdbms
---
You received this message because you are subscribed to the Google Groups "Pick and MultiValue Databases" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mvdbms+un...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/mvdbms/101e150a-68d9-43bb-86a1-fecf0e96eb8dn%40googlegroups.com.

[Eric Karmark]

jsh JBASEADM ~ -->jshow -c TEST
Shared Object:            C:\jBASE\JBASEADM\bin\TEST.dll
                          jBC main() version 6.2 Fri Apr 17 17:44:31 2026
                          jBC main() source file BP
Executable: (DUP!!)       C:\jBASE\JBASEADM\bin\TEST.exe
                          jBC main() version 6.2 Fri Apr 17 17:44:31 2026
                          jBC main() source file BP
jsh JBASEADM ~ -->

[bdeck...@gmail.com]

Feels like either something is missing from the C compiler setup or something got botched when this release was built (Like the C++ build tools were present on the developers machine who built the release) and now it’s expecting something to be there, like link.

 

This doesn’t seem right and RUN does work (I use it on Linux).  I just don’t do much work on Windows.  As you say, RUN is archaic but it does have a place in legacy code.  I’ll pass this along to our support department for a deeper dive but you should also open a support case.

 

If you just want it to work, you can write your own wrapper called RUN and put it in path ahead of jBASE’s RUN.  The wrapper would just toss away the RUN and the FILENAME and just CHAIN the program.

 

The support guys hate it when standard commands are wrapped, so you need to be careful and own it when you wrap.

 

-BD

To view this discussion visit https://groups.google.com/d/msgid/mvdbms/71eed143-a2f1-4956-b37c-f3e711b8336bn%40googlegroups.com.

[Eric Karmark]

Many thanks for the response on this - I think you're right on something not being quite right in the 6.2 build - I had Gemini create a synopsis of what it concluded and it might be something of interest to jBase devs but I'm not sure about opening a ticket given this is just for 'hobby' purposes:

Gemini TL;DR below...

In earlier versions of jBASE, BASIC was more of a "suggestion" to compile, but in 6.2, the move toward JIT (Just-In-Time) compilation and the JELF standard became much more aggressive.

Here is the technical breakdown of how that change specifically screwed you on Windows but played nice on Linux:

1. The Death of the "Intermediate" Object

In older versions, BASIC produced an .obj file, and CATALOG produced a .dll. In 6.2, jBASE tries to streamline this by using a high-performance JELF loader.

• On Windows: This new loader is incredibly picky. It expects the binary to have a specific "jBASE-ready" signature. If the Windows compiler (MSVC) isn't called with the exact flags jBASE 6.2 expects, it produces a standard DLL. The 6.2 RUN command sees that standard DLL, realizes it's missing the 6.2-specific JELF metadata, and refuses to run it.

• On Linux: The ELF format used by Ubuntu is much closer to what the JELF loader wants. The 6.2 engine on Linux can "wrap" a gcc output almost instantly without the metadata conflicts you hit on Windows.

2. $PROG vs PROG.dll

jBASE 6.2 introduced a change in how it looks for code. If it doesn't see a perfectly cataloged JELF-status binary, it tries to "auto-catalog" or look for an intermediate record (the ones prefixed with $).

• On Windows, this search logic often gets stuck in a loop. It finds the .dll, sees it's not "JELF enough," then looks for the $PROG record, which might be corrupt or missing because of that Maxtor drive.

• This is why you were seeing the error: Unable to find JELF status on file $TEST. The 6.2 engine was essentially saying, "I found the file, but I don't recognize the 6.2-style signature in the header."

3. The Compiler "Embedded" change

Starting with the later 6.x builds, jBASE tried to move toward more "embedded" compilation logic to reduce the reliance on external paths.

• On your Ubuntu VM, the integration with gcc is baked into the 6.2 installer much more cleanly.

• On Windows, it still relies on that external "handshake" with Visual Studio. If that handshake isn't 100% perfect (which it wasn't for us), the 6.2 RUN command simply won't trust the resulting binary.

The "TL;DR" of 6.2: Version 6.2 raised the bar for what it considers a "valid executable." Windows makes it hard to clear that bar; Linux clears it by default.