#219 closed defect (fixed)
Error loading Lucide.dll: can't find module 'LIBC063' (SYS002)
Reported by: | Rainer | Owned by: | |
---|---|---|---|
Priority: | minor | Milestone: | 1.3.3 |
Component: | Lucide Core | Version: | 1.3 |
Keywords: | Cc: |
Description
Version 1.3.0 to 1.3.3 Beta
The "new" plausibility / loading for DLL modules does not check the DIR / DLL via BEGINLIBPATH.
Lucide does not find the DLL s and display a Message "... (SYS002)"
Test Case:
the Modules LIBC063 are not in LIBPATH but in Beginlibpath
rem Lucide.cmd Version 1.0 2007-11-05 Rainer
rem Lucide-1-21.cmd 2009-02-28 Rainer
rem Lucide-1-30.cmd 2010-04-12 Rainer
rem mode co100,80 gives more space for test output to look at
rem mode co100,80
SET LIBPATHSTRICT=T
SET BEGINLIBPATH=S:\download\os2\gcc442;S:\download\os2\libc063;S:\download\os2\UClib;
s:
cd \download\os2\LUCIDE\V1-30
lucide.exe %1 %2 %3 %4 %5 %6 %7
cd \
rem pause
Kind Regards
Rainer
PS: the Lucide trac does not offer versions above 1.3
Attachments (1)
Change History (9)
comment:1 by , 14 years ago
comment:2 by , 14 years ago
what timestamp and size does the libc063.dll have?
Verzeichnis von T:\apps\libc063
11.03.09 23.00 <DIR> 0 .
11.03.09 23.00 <DIR> 0 ..
29.12.08 20.10..... 26934 ......... 0 COPYING.LIB
29.12.08 20.10 .... 32801 ......... 0 gcc335.dll
29.12.08 20.10 ... 762523 ......... 0 libc-0.6.3-csd3.ZIP
29.12.08 20.10 .... 48142 ......... 0 libc06.dll
29.12.08 20.10 .... 48142 ......... 0 libc061.dll
29.12.08 20.10 ... 157124 ......... 0 libc062.dll
29.12.08 20.10 .. 1349060 ......... 0 libc063.dll
9 Datei(en) 2424726 Byte belegt
733232640 Byte frei
[T:\apps\libc063]
Additional Info:
Workaround: copy the modules from dir Libc063 to the Lucide dir
==> no message box at program start
The CMD for executing lucide is from an other of my installations.
The path names are not consistent :-)
The version of LIBC063 is the same on all my installations
kind regards
Rainer
comment:3 by , 14 years ago
Resolution: | → wontfix |
---|---|
Status: | new → closed |
sorry but we have no time to test such non standard installations.
comment:4 by , 14 years ago
Hallo diver,
the usage of the OS/2 environment variables BeginLibPath, EndLibPath and LIBPATHSTRICT are standard OS/2 functions.
An OS/2 program should work according the specification to handling these values!
Otherwise it is defect.
Lucide 1.21 does work according these standards, 1.3x does not!
kind regards
Rainer
comment:5 by , 14 years ago
I guess your problem has nothing to do with Lucide. We don't block BEGINLIBPATH and it's not possible in principle to do so (this variable is handled by the OS/2 loader before the EXE gets control). Please check your environment and paths. Some other DLL is probably missing (you didn't give a complete error message so it's not clear which one).
by , 14 years ago
Attachment: | lucide-1-32-test-doc.zip added |
---|
comment:6 by , 14 years ago
Please check your environment and paths. Some other DLL is probably missing (you didn't give a complete error message so it's not clear which one).
Hallo dmik,
your points have been checked again.
A la Stalin ( trust is good , control is better :-) or the four eyes check and balance :-)
you can check my test, I have documented the tests and the output
- your can see displayed error message and compare it with the subject line See the screen shoot of the message box of the attachment.
- the my environment and path are documented with a test.cmd file and the output of the two cases
- LIBC063.dll only in DIR defined in BeginLibPath Case ... BOX-yes.txt
- LIBC063.DLL in the BeginLibPath and in the current dir case ... BOX-no.txt
Please check the attachment files
kind regards
Rainer
comment:7 by , 14 years ago
Resolution: | wontfix → fixed |
---|
(In [467]) launcher: Retain the previous BEGINLIBPATH setting since loading lucide.dll may fail otherwise if some of its prerequisites (like libc063.dll) are located in a path from that previous setting and LIBPATHSTRICT=T mode is used (fixes ticket:219).
comment:8 by , 14 years ago
Okay, we did not block BEGINLIBPATH but we overwrote it when loading lucide.dll so that if something needed by it was in the previous BEGINLIBPATH specification (like LIBC063.DLL in your case) it could not find it. Quite non-typical situation but overwriting BEGINLIBPATH (instead of ap-/pre-pending to the current value) is a bad practice anyway. Fixed now.
what timestamp and size does the libc063.dll have?