Upgrade from 1.3.5 GA to 1.4.0 produces no working plugins.

[darcio]

To be clear, I did not use RPM/YUM to install. Instead I followed the README details and downloaded all the applicable packages and extracted just the DLLs. I then cross-referenced this with the ZIP version of the packages (as available on the netlabs ZIP folder) and confirmed the right DLLs were available.

By default no plugins are recognized. The only way I can get any plugins to be activated is to move the 1.3.5 GA version of the DLL into the Lucide 1.4.0 program working directory.

This implies the poppler/djvulibre/libjpeg installations are non-functioning. I suspect I am missing some other DLL, or that the RPM/YUM install method itself re-organizes the OS/2 install in some other way beyond the drop of the correct DLLs.

[Lewis Rosenthal]

To be clear, it is not that the plugins aren't recognized, but rather, they likely can't load due to missing dependencies.

The dependent libraries themselves have dependencies. Did you verify that those were met?

Is there some reason that you did not use ANPM to install the dependencies?

Copying the old plugins from 1.3.5 will get you, well, old plugins. They are static (no other real dependencies), so they work, but the latest plugins will always require the system-installed libraries.

I recommend you download and install PMDLL from Hobbes and select the following dlls to check for missing dependencies:

• ludjvu.dll
• lujpeg.dll
• lupplr.dll

That will tell you what's still missing. It may be just one library or it may be several.

[darcio]

OK, some changes in my approach to keeping the OS/2 box udpated...I bit the "bullet" and moved to ANPM. My hope was that this would allow me to seamlessly keep up with the direction our OS/2 platform is pursuing.

So what does that mean? Well, I have ANPM v1.0 installed successfuly. I also executed the install/update of all the packages listed in the Lucide (v1.40 b3) README, those being:

START

... To install all prerequisites in one go from Arca Noae Package Manager, simply copy and paste the following string into the Quick install dialog:

libc libgcc1 libgcc-fwd poppler poppler-data libjpeg djvulibre uclip ...

STOP

...however, the Lucide project netlabs page states the following instead:

START

...

For version 1.4.0 and newer, the Quick install list is:

libc libgcc1 libgcc-fwd gcc-stdc++6 gcc-supc++6 poppler poppler-data libjpeg djvulibre uclip ...

STOP

And I'm looking at this because following the ANPM install of the required Lucide packages attempting to open any PDF file causes the following error to show up in POPUPLOG.OS2:

START

10-16-2016 11:51:46 SYS2070 PID 009e TID 0004 Slot 00cb G:\APPS\GENERAL\LUCIDE\LUCIDE.EXE POPPLE63->SMIME3.168 182

STOP

Trying to find the cause of the problem led me down the path of attempting to install the two packages which the website shows that are not listed in the README, these being: gcc-stdc++6 and gcc-supc++6...however, ANPM does not find these packages anywhere (netlabs or arcanoae).

So what is the right next step? Find the 2 missing packages, or troubleshoot the error message on it's own?

Thanks!

[darcio]

Ahh...one more update, I noticed an updated libjpeg packaed available from netlabs-exp, should I give that a try?

[Lewis Rosenthal]

netlabs-exp: No, not yet.

The two packages were renamed somewhere along the line. Try:

libstdc++6 libsupc++6

I have updated the wiki page to reflect the current names and the new readme for 1.4.0 now agrees with the list on the wiki (I think/thought the above two were installed along with something else and should be unnecessary at this point, but your experience seems to indicate otherwise).

Please install those two from netlabs-rel and report your results!

[darcio]

Alright, so libstdc++6 was already installed, but I did install libsupc++6.

Still, I am getting the same error, however, there is something else I noticed. If I open Lucide shortly after a re-boot, all is good, no problems. However, as I start using my normal apps, eventually something apparently causes a conflict because on subsequent Lucide starts I produce this error.

I will test further to see what's actually causing the problem. Previously all my additional DLLs were stored in \usr\dll directory. Now ANPM stores them in \usr\lib. My first step to "clean-up" was to delete the usr\dll\xxx.dlls which are older then \usr\lib\xxx.dlls. However I can not simply delete all the \usr\dll\xxx.dlls since WarpIn put them there and there are probably other apps that require them.

Soo....next step was to use DLLTree and do a dynamic load with a PDF file being passed as an input parameter. This identified a single dll from \usr\dll which was being loaded. No idea if this is the culprit or not, but I'm attaching the DLLTree load output for your reference. I will re-do this load right after a re-boot to see if there are any differences.

[darcio]

Also attaching a full file listing dump of my \usr directory to give you better visibility of what's there, especially the old \usr\dll and the new \usr\lib sections.

[darcio]

\usr directory structure file listing

[darcio]

I uploaded both the FAIL & PASS DLLTree loads of Lucide. The big difference (aka: the failure root cause/culprit) is that the FAIL happens as soon as I have Firefox up and running.

My machine still has the old 17.0.11 release, althought part of the ANPM drive was to get to the most recent 38.8.x release, so that's the next thing on my list.

Anyways, I tried to make sense of what DLLTree shows, but not being familiar enough with the Lucide structure it is somewhat like looking for the "needle in the haystack".

OK, but to me it looks like SMIME3.DLL is most likely the problem. The DLLTree load shows different stuff being loaded when the Lucide LUPPLR.DLL loads SMIME3.dll. When Firefox is running the failing Lucide run picks up the Firefox version of SMIME3.DLL (which is present in the Firefox directory).

The Firefox version shows as:

Module : SMIME3.DLL Loaded from : G:\APPS\TCPIP\FIREFOX\SMIME3.DLL File size : 70,701 bytes File date/time: 10-17-14 09:58:34 pm

I will take a stab in the dark and will try to rename that DLL in hopes that Firefox will be OK with the newest YUM/RPM instead. More to follow...

[darcio]

Good news...for now...LOL...renaming the Firefox DLL allowed Firefox to pull in the latest YUM/RPM one, which now means that Lucide is able to load while Firefox is up and running.

I will monitor the situation over the next few days and will provide an update at that time. No idea here what impact the latest SMIME3.DLL will have on my old Firefox version...remains to be seen I suppose.

Let me know if you have some other ideas and/or information I should follow-up on.

[darcio]

More info..unfortunately not the happy type...LOL.

I had to go back to the original FF17.x SMIME3.DLL because attempting to use the latest YUM/RPM package one actually would cause my machine to lock-up hard, as in only CTL-DEL-NUMLOCK (dump) and then CTL-ALT-DEL would get me out.

So is there anything that can be done about this, or is the latest version of Lucid inherently incombatible with FF17.x releases?

Thanks!

[Lewis Rosenthal]

Just copy the latest one to the Lucide program directory, ensuring that the "." is the first entry in LIBPATH.

[Lewis Rosenthal]

Conversely, copy the older SMIME3.DLL to the FF17 directory and upgrade SMIME3.DLL to the latest version (probably makes more sense).

[darcio]

Replying to lewisr:

Conversely, copy the older SMIME3.DLL to the FF17 directory and upgrade SMIME3.DLL to the latest version (probably makes more sense).

Well, that is literally how things are set up right now...but of course that prevents me from being able to run Lucide as long as FF is up and running...sort of defeating the purpose of having a PDF viewer that could be called from my web-browser. So in reality, this is not a workable solution.

Trying your other suggestion leads to a complete hard-lock, meaning only CTL-DEL-NUMLOCK & CLT-ALT-DEL recovers with the necessary re-boot.

[Lewis Rosenthal]

If you set LIBPATHSTRICT, you should be able to run whichever app is using the non-default SMIME3.DLL. If you use Go you may do this, as well. This should work assuming "." is either first in LIBPATH or is first in BEGINLIBPATH set for the particular session.

So, for FF17 with the older SMIME3.DLL, for example, ensure:

• "." is either first in LIBPATH or is first in BEGINLIBPATH for the session
• LIBPATHSTRICT is set for the session
• Start FF17 from its directory, so that "." is the FF17 directory

FF17 should then start and load its local DLLs - including SMIME3 - from ".", and everything else on the system should run normally, loading the current SMIME3 from %UNIXROOT%\usr\lib.

I have not tested this, but this makes sense to me. It is possible, of course, that spawning Lucide from FF17 may pass LIBPATHSCTRICT to its environment (I'd have to think about that some more).

The point is that if making special allowances, generally, the newest versions should be the default versions and the older ones should be the exceptions. So, if something needs and older DLL, the point is to find a way to give that the older one, and leave all of the newer stuff alone. Well, that's the theory, at least.

Sorry about the lockup. Best guess is/was the missing LIBPATHSTRICT.

[darcio]

Ahh...OK, I tried the other way, which was to run the 38.8.x drop of Firefox with the LIBPATHSTRICT setting and let the 17.x release run against the standard DLLs it came with.

Of course the Lucide run was "wide open", meaning I did not use LIBPATHSTRICT and since my FF 17.x did not use it either therefore the DLL conflict which caused the hard-lock.

But...and I'm knocking on the proverbial "wood" here, because I took out the following FF 17.x DLLs and replaced them with the new YUM/RPM releases...this now allows me to run Lucide and produces no hard lock-ups.

The original FF 17.x DLLs which I "removed" from operation are:

freebl3.dll.original nspr4.dll.original nss3.dll.original nssckbi.dll.original nssdbm3.dll.original nssutil3.dll.original plc4.dll.original plds4.dll.original smime3.dll.original softokn3.dll.original ssl3.dll.original

Again, this way, if no lock-ups occur I am hoping will allow me to transition to the YUM/RPM releases as seamlessly as possible.

The other approach would be to try exactly what you suggested regarding running FF 17.x with LIBPATHSTRICT...only unknown there would be regarding the plug-ins/extensions (such as Lucide) and how they execute.

Thanks again, I will report out on the progress in a couple of days.

[Lewis Rosenthal]

Can this ticket be closed?