Error in loading JPL

[Rex]

I got the following error in loading JPL with all versions I tested on Windows 7 x64, including SWI-Prolog 6.6.6, 7.1.6, 7.1.8, both of x64 and x86 versions.

ERROR: c:/progra~1/swipl/library/jpl.pl:4668:
        '$open_shared_object'/3: The specified module could not be found.
ERROR: Exported procedure jpl:jpl_c_lib_version/1 is not define

Attached is the relevant trace result. It seems to be caused by load_foreign_library(foreign(jpl), jpl, default(install)). It was failed to find some specified module. In a further trace of this predicates, it promts a windows saying "The program can't start because jvm.dll is missing from your computer...." Although the folder of jvm.dll is within my windows %Path%.

?- trace.
[trace]?- use_module(library(jpl)).

   Exit: (48) link_xpce:pcehome_('c:/progra~1/swipl/xpce') ? creep
   Exception: (33) shlib:load_foreign_library(foreign(jpl), jpl, default(install)) ? creep
^  Call: (35) notrace(print_message_lines_guarded(current_output, [begin(error, _G1596), '~NERROR: ~w:~d:'-['c:/progra~1/swipl/library/jpl.pl', 4668], nl, prefix('~N\t'), '~q/~w: '-['$open_shared_object'|...], '~w'-[...], nl|...])) ? creep
ERROR: c:/progra~1/swipl/library/jpl.pl:4668:
        '$open_shared_object'/3: The specified module could not be found.

^  Exit: (35) notrace(print_message_lines_guarded(current_output, [begin(error, ansi('\033\[0m')), '~NERROR: ~w:~d:'-['c:/progra~1/swipl/library/jpl.pl', 4668], nl, prefix('~N\t'), '~q/~w: '-['$open_shared_object'|...], '~w'-[...], nl|...])) ? creep

   Call: (29) expand_term(end_of_file, 158478-158489, _G1544, _G1545) ? creep
   Exit: (29) expand_term(end_of_file, 158478-158489, end_of_file, 158478-158489) ? creep
   Call: (31) true ? creep
   Exit: (31) true ? creep
^  Call: (30) notrace(print_message_lines_guarded(current_output, [begin(error, _G1573), prefix('~NERROR: '), 'Exported procedure ~q:~q is not defined'-[jpl, jpl_c_lib_version/1], nl, end(_G1573)])) ? creep
ERROR: Exported procedure jpl:jpl_c_lib_version/1 is not defined
^  Exit: (30) notrace(print_message_lines_guarded(current_output, [begin(error, ansi('\033\[0m')), prefix('~NERROR: '), 'Exported procedure ~q:~q is not defined'-[jpl, jpl_c_lib_version/1], nl, end(ansi('\033\[0m'))])) ? creep
^  Call: (25) notrace(print_message_lines_guarded(current_output, [begin(informational, _G3081), prefix('~N% '), '~|~t~*+'-[0], '~p'-[library(jpl)], ' ~w'-[compiled], ' into ~w'-[...], ... - ...|...])) ? creep
% library(jpl) compiled into jpl 0.42 sec, 552 clauses
^  Exit: (25) notrace(print_message_lines_guarded(current_output, [begin(informational, ansi('\033\[0m')), prefix('~N% '), '~|~t~*+'-[0], '~p'-[library(jpl)], ' ~w'-[compiled], ' into ~w'-[...], ... - ...|...])) ? creep
true.


I googled and found this error is not rare, but did not got any good solution yet. Any suggestion would be greatly appreciated.


Kind regards,
 - Rex

[Rex]

After one night debugging, I got a solution:
copy jvm.dll into %SWI_HOME_DIR%\bin

Now the magic shows!

Have a good night everyone :)

Kind Regards,
Rex

[Paul Singleton]

On Saturday, 2 August 2014 07:04:52 UTC+1, Rex wrote:

..."The program can't start because jvm.dll is missing from your computer...." Although the folder of jvm.dll is within my windows %Path%.

 then

After one night debugging, I got a solution:
copy jvm.dll into %SWI_HOME_DIR%\bin

It is better to leave jvm.dll where it was installed, and tell SWI-Prolog where to find it: despite what you believe about %PATH%, it clearly didn't find it.

Sun/Oracle JREs hide jvm.dll in subfolders e.g. C:\Program Files\Java\jre7\bin\client

I suggest writing a .bat file to invoke swipl-win.exe with an explicit minimal PATH, e.g. (your 64-bit mileage will definitely vary)

set PATH=C:\WINDOWS\system32;C:\WINDOWS;C:\swipl\bin;C:\Program Files\Java\jre7\bin;C:\Program Files\Java\jre7\bin\client
swipl-win.exe

Get this working, then adjust your user or system environment correspondingly

Paul Singleton

[Rex]

Dear Paul,

Thanks for your tips. Your solution works in loading JPL:
      ?- use_module(library(jpl)).

But when I
      ?- jpl_call( 'jpl.JPL', version_string, [], Vj).
the SWI-Prolog window automatically closes without any error message.

Any further suggestion?


Kind regards,
 Rex

[Rex]

In Windows 7 x64 cmd,

C:\swipl\bin>set Path=C:\WINDOWS\system32;C:\WINDOWS;C:\swipl\bin;c:\progra~1\Java\jdk1.7.0_51\bin;C:\Progra~1\Java\jdk1.7.0_51\jre\bin\server
C:\swipl\bin>swipl

1 ?- use_module(library(jpl)).
%   library(pairs) compiled into pairs 0.02 sec, 22 clauses
%  library(lists) compiled into lists 0.02 sec, 122 clauses
% Extended DLL search path with
%   'c:\\progra~1\\Java\\jdk1.7.0_51/jre/bin'
%   'c:\\progra~1\\Java\\jdk1.7.0_51/bin'
% library(jpl) compiled into jpl 0.17 sec, 1,853 clauses
true.

2 ?- jpl_call( 'jpl.JPL', version_string, [], Vj).
Error occurred during initialization of VM
Unable to load native library: Can't find dependent libraries

It seems there is still some problem in finding the right %JAVA_Home% path.
However, java_home is correct.
 ?- java_home(X).
Correct to: "jpl:java_home(X)"? yes
X = 'c:\\progra~1\\Java\\jdk1.7.0_51'.

[Paul Singleton]

SWIPL has found and loaded a jvm.dll which is not in its original (as installed) folder.

That stray jvm.dll gets loaded, but it cannot then find its bootstrap files in adjacent folders as it expects, and cannot initialise.

NB embedded swipl-win.dll works similarly when loaded from "foreign" (i.e. native) code: see http://www.swi-prolog.org/pldoc/man?section=findhome bullet 4.

Delete all such copies of JRE (or JDK) files; ensure your JRE is exactly as it was originally installed; configure PATH and CLASSPATH correctly; report your success ;-)

Paul Singleton

[Rex]

Followed your advice, problem solved!

I set up a short necessary path for SWI and JPL in a cmd console, and then run swipl.

One problem found here is there seems to be a character length limit in fetching the %Path% environment variable on Windows. I tested different %Path% lengths, and found the character length limit is 1021. Over that, one will get "file name contains a 0-code" error.

Thank you.

Kind Regards,

 Rex

--
You received this message because you are subscribed to a topic in the Google Groups "SWI-Prolog" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/swi-prolog/Tq88LtCXCPo/unsubscribe.
To unsubscribe from this group and all its topics, send an email to swi-prolog+...@googlegroups.com.
Visit this group at http://groups.google.com/group/swi-prolog.
For more options, visit https://groups.google.com/d/optout.

[Anne Ogborn]

Jan - this problem's been around forever, and isn't going away anytime soon. 

Microsoft officially says they won't fix the problem.

So, can we do something to protect ourselves from it? Maybe issue a warning if the path contains nulls at startup?

The worst thing about it is the lack of any warning that something's wrong. You just get to grovel through your problem, like these guys did.

[Jan Wielemaker]

On 08/06/2014 09:24 PM, 'Anne Ogborn' via SWI-Prolog wrote:
>
>
> Jan - this problem's been around forever, and isn't going away
> anytime soon.�
>
> Microsoft officially says they won't fix the problem.

Great! I always appreciate the bug compatibility of proprietary software
:-)

> So, can we do something to protect ourselves from it? Maybe issue a
> warning if the path contains nulls at startup?

That is a bit drastic, no? Quite often the variable won't be used in the
application or the bad value is not fatal. That is why I once added the
"file name contains a 0-code" error, giving the user at least a hint at
the moment that such illegal values are actually used to resolve files.
But true, it is only a sensible hint for the really experienced user :-(

> The worst thing about it is the lack of any warning that something's
> wrong. You just get to grovel through your problem, like these guys
> did.

I guess the best is to add some checks to the "LOAD THE JVM" section of
jpl.pl that verifies sanity of the environment variables actually being
used and print a sensible error message (and ask people to complain with
M$).

An alternative would be to add rules to check_installation/0, which is
there to validate the sanity of an installed system and point people at
solutions (only in SWI-7).

Patches welcome :-)

Cheers --- Jan

[Anne Ogborn]

Patches welcome :-)





ok, I'll send one in next few days.

[Mariano Phielipp]

Hi

 So, what was the final solution. I still get the 

% Unknown message: 'c:/program files/swipl/lib/x64-win64/jpl.dll'

ERROR: c:/program files/swipl/library/jpl.pl:4699:

        '$open_shared_object'/3: The specified module could not be found.

and

% Unknown message: 'C:\\PROGRAM FILES\\JAVA\\JRE7\\BIN\\SERVER\\jvm.dll'

ERROR: Exported procedure jpl:jpl_c_lib_version/1 is not defined