Author Topic: qpdfview  (Read 34610 times)

Doug Bissett

  • Hero Member
  • *****
  • Posts: 1593
  • Karma: +4/-2
    • View Profile
Re: qpdfview
« Reply #30 on: March 08, 2015, 06:34:28 am »
Quote
You have a choice, if you don't like what's on offer, don't use it.

I don't use YUM, except to test the new Arca Noae Package Manager (AKA Yumie). Yumie works great, when YUM doesn't screw up, which happens far too often. The results of that project have pretty well convinced me that YUM is definitely not the answer to the problem, and somebody has got to tell the developers that. It makes them look bad, and it makes using OS/2 impossible, for many new OS/2 users.

Quote
There is no need to denigrate the people who are doing stuff to try and help OS/2.

The problem is, that they are not exactly helping anybody, when their software doesn't work properly. YUM is well known be a major problem in the *NIX world, and many *NIX versions have moved on to something else. Denying that YUM is a problem is self defeating. It will not get any better, simply because the source code isn't good. Lets bite the bullet now, and get on with life.

Now, it seems that I have a problem with PTHREAD, that I will admit I haven't got around to reporting (sorry, life got in the way).

I will point out that nobody ever mentioned that GCC1 was in progress, and I never heard of anybody suggesting that people should test it. That is exactly the same sort of thing that caused so many problem for eCS 2.2 b1. The assumption was made that it worked on a dozen machines, so it would work on all of them. WRONG!

Enough said about that. If they have any sense, they will move on, and do it right. If not, it is just one more nail in the coffin.

Quote
I see png16.dll is missing.

I find that file in my DLL collection. I am not sure where it came from, but it is likely in an older version of libpng. The latest one seems to call it png1616.dll, for some reason.

Dave Yeo

  • Hero Member
  • *****
  • Posts: 4787
  • Karma: +99/-1
    • View Profile
Re: qpdfview
« Reply #31 on: March 08, 2015, 07:33:31 am »
At this point we have yum/rpm, it seems to be the tool that the developers are used to and they're going to keep using. It's not my ideal and I've spent a fair amount of time cursing yum/rpm as it is very fragile but I don't have the energy or knowledge to take over the job and as they seem to be working for close to free and we're on a dying platform it is really not constructive to rant.
All we can do is comment on how we feel or how we find the experience and let things flow how they will. Doesn't hurt to do things to make the flow go better, testing and reporting and making whatever contributions that we can, even if it is only making the install instructions clearer.

Andi B.

  • Hero Member
  • *****
  • Posts: 811
  • Karma: +11/-2
    • View Profile
Re: qpdfview
« Reply #32 on: March 08, 2015, 11:22:31 am »
I don't use YUM,
That might be part of your problem.

Quote
The problem is, that they are not exactly helping anybody, when their software doesn't work properly.

It was proved numerous times that it's nearly impossible to help people how have spread different dlls coming from unknown sources all over their system. Especially when they ignore the fact that they have driven themselves into an inscrutable dll hell and neglect to clean it up.

Currently the only way to keep dlls which are needed for ported software in a current consistent state is yum/rpm. No one offers a better way for doing this so it makes absolutely no sense to constantly ranting about. Come up with a better solution and I'm willing to discuss the pro and cons.

What a user needs to do for cleaning up his mess would be searching all drives for duplicates of every dll in %unixroot%/usr/lib. Tools like DataSeeker, pmseek, SearchPlus can be used for this. But this is a time-consuming task of course.

Quote
I find that file in my DLL collection. I am not sure where it came from, but it is likely in an older version of libpng. The latest one seems to call it png1616.dll, for some reason.
I do not have a png16.dll in my libpath and qpdfview works. qpdfpdf.dll needs png1616.dll. Here's the dll loading tree -

Neil Waldhauer

  • Hero Member
  • *****
  • Posts: 1024
  • Karma: +24/-0
    • View Profile
    • Blonde Guy
Re: qpdfview
« Reply #33 on: March 08, 2015, 03:25:25 pm »
I found that png16.dll was loaded by freetyp6.dll. I suppose it's useful to put timestamps or other versioning into dll files, but no one else is, so I won't, either. Anyway, a version of freetyp6.dll was in my libpath before the one in \usr\dll and it tried to load png16.dll, which wasn't present. Removing that version of freetyp6.dll allows the one in \usr\dll to load, and qpdfview works.

The tool I use to manage libpath is inadequate. I have which.exe from the EMX days. It doesn't show the DLLs well enough. Is there a newer version of which?

Usage: which <command>...
       which -d <dll>...

It's a simple, but good tool for finding things.
Expert consulting for ArcaOS, OS/2 and eComStation
http://www.blondeguy.com

ivan

  • Hero Member
  • *****
  • Posts: 1557
  • Karma: +17/-0
    • View Profile
Re: qpdfview
« Reply #34 on: March 08, 2015, 03:42:11 pm »
Hi Andi B,

Quote
Currently the only way to keep dlls which are needed for ported software in a current consistent state is yum/rpm. No one offers a better way for doing this so it makes absolutely no sense to constantly ranting about. Come up with a better solution and I'm willing to discuss the pro and cons.

In actual fact it isn't.  We have a policy that we have to adhere to for our clients, we can't use anything that is not approved and in the case of anything going onto the machine control computers certified.  This means that we can not use RPM/YUM as I doubt it would get approval and certainly not certification.

We get round this by having either program objects that are very specific in how they start and run a program or programs are started by command files, again with very specific parameters.

At the moment I am experimenting with using a directory directly off the root of the boot drive to hold all these extraneous DLLs that is listed in the libpath of config.sys.  This works and because I back it up before any additions are made it is very easy to go back to what was working if anything breaks (I have had to do this a couple of times).

Now back to Qpdfview.

Looking over the zip files of Qpdfview I find that v0.4.9 and v0.4.10 both have some of the required DLLs included while later versions do not.  Also reading the README from the latest source it appears there are a number of options that can be used when building, some of which would solve some of the problems we are seeing - for instance, not everyone can get CUPS printing to work so why is it a built in requirement and must be installed for this port to work?
 

Doug Bissett

  • Hero Member
  • *****
  • Posts: 1593
  • Karma: +4/-2
    • View Profile
Re: qpdfview
« Reply #35 on: March 08, 2015, 05:05:29 pm »
Quote
Quote from: Doug Bissett on Today at 06:34:28 am

   
Quote
I don't use YUM,


That might be part of your problem.

No. I have the same problems on my systems that do use YUM, in fact, I could argue that I have worse problems on those systems. It appears that I am going to have to bite the bullet, and quit using one, or more, of my background programs, to free up more shared memory space. I am not sure what I am going to stop using, but something needs to be done about that problem, and using more DLLs is definitely not the answer.

Quote
The tool I use to manage libpath is inadequate. I have which.exe from the EMX days. It doesn't show the DLLs well enough. Is there a newer version of which?

Usage: which <command>...
       which -d <dll>...

It's a simple, but good tool for finding things.

One of the problems with 'which' is that you need to remember to run it from the working directory of whatever you are trying to diagnose. It needs to follow the dot entry in LibPath, which is usually very near the beginning.

Quote
At the moment I am experimenting with using a directory directly off the root of the boot drive to hold all these extraneous DLLs that is listed in the libpath of config.sys.  This works and because I back it up before any additions are made it is very easy to go back to what was working if anything breaks (I have had to do this a couple of times).

I think that I am going to start doing something like that, on one (test) system, then I will use RSYNC to keep all of my systems updated to what works on the test system (still no guarantee that updates won't cause problems, but...). I haven't tried that, yet, but I suspect that I will have to unlock all of the files to be able to update them, and a reboot may also be a good idea. If somebody has an available server, with RSYNC, everybody could update that way.

The biggest problem is to sort out which DLLs belong in a common system directory, and which ones belong in a program directory. Too many programs have been distributed with common system DLLs in their program directory, and that seems to be part of what is causing trouble. Those need to be removed, to avoid duplicates, and down level versions. Another problem is that some programs are distributed with down level files, which replace the later level files. That makes the "new" program work okay, but it can break something else. It also appears that none (or very few) of the ported DLLs have BLDLEVEL information in them, and that complicates the whole thing too.

Quote
not everyone can get CUPS printing to work so why is it a built in requirement and must be installed for this port to work?

It has been said, that all you need is CUPS.DLL, somewhere in your LibPath. I can't vouch for that because I do have CUPS installed. There is also the problem where later versions of CUPS supply one of CUPS.DLL, CUPS17.DLL, or CUPS20.DLL. QPDFView (and some other programs) don't know about the last two. Of course, if you do put CUPS.DLL somewhere in your LibPath, then install CUPS later, you are exposed to having a problem, if you forget about that.

Then, there is the major problem of installing RPM/YUM, after you have updated things in other ways. YUM puts the path to what it installs first, which works okay, but it leaves behind the old stuff. Now, depending on what gets started first, you may have a down level version being used, which will break things that need the later version. This results in "sometimes it works, and sometimes it doesn't". Those problems can become extremely difficult to fix.

I will note one other thing, that I suspect few OS/2 users know anything about. Some of these ports are using the *NIX concept of "SYMLINKS". From what I understand, that allows the program to go looking for another program, which may not actually exist, but the program name has a method to run a different program in it's place. (Confused yet?). So you never know what you are really using, and that makes trouble shooting extremely difficult, especially when you look in the file of the first program, and find a path to the second program, rather than code. (Now, you should be totally confused). Somehow, I don't see this as being a good thing.

I will also mention the tool that is part of X(e)Workplace, called 'OS/2 Kernel'. Part of this tool will list your PATH statements (LibPath, Path, DPath), and determine if there are invalid paths. It also lists duplicate files found in the paths. Of course, it has the same problem as 'which' (mentioned above), because it cannot properly follow the dot entry in LibPath. One needs to be very careful when trying to analyze these things, and understand which file will be found first, under various circumstances.

Andi B.

  • Hero Member
  • *****
  • Posts: 811
  • Karma: +11/-2
    • View Profile
Re: qpdfview
« Reply #36 on: March 09, 2015, 09:33:04 am »
Ivan -
Quote
for instance, not everyone can get CUPS printing to work so why is it a built in requirement and must be installed for this port to work?
I can only speculate on this -
- maybe the majority of users who read pdfs have sometimes the need to print part or whole pdf (like me)
- maybe the creator team of this program decided that they need to print sometimes and they decided the way to go is cups
- maybe the porter of this application does follow the above arguments or simply did not see any sense in cutting out code he ported from the qpdfview project (and increasing his own workload considerable) only to make one OS/2 user happy while distress a lot of others 

Of course you can ask on qpdfview user or developer list this topic. But for me such discussions are as useless as a hole in the head. And fear the developers of qpdfview will see it similar. They use some *nix system where cups is standard. If I should speculate again they will say that's the way it is, take it or leave it.

which is not the answer for cleaning up old dlls. 'which -lasu libc065.dll' can only find dlls in current directory and libpath. But not the ones which are loaded by some application in theirs directory regardless if you have . in libpath or not. Btw. that's the reason why I implemented in my which port a warning message about that fact. And that's why I wrote above -
Quote
What a user needs to do for cleaning up his mess would be searching all drives for duplicates of every dll in %unixroot%/usr/lib. Tools like DataSeeker, pmseek, SearchPlus can be used for this.
Problem is too many users copied some dlls into some directories all over their system and now reap what they sow. Ways to start cleaning of a system are
- run one of the above tools at least for all dlls and dependencies listed in the readme
- double check with which -lasu all these dlls (you can use pmdll to get the list of dlls but you have to repeat this step)
- check all your programs you start automatically or manually after reboot for dlls they use and where they are placed on your system

Another method would be reinstalling eCS WITHOUT manually changing libpath afterwards (I hate to suggest the Windoze way)

guzzi

  • Sr. Member
  • ****
  • Posts: 331
  • Karma: +0/-0
    • View Profile
Re: qpdfview
« Reply #37 on: March 09, 2015, 01:40:56 pm »
Ivan -
Quote
for instance, not everyone can get CUPS printing to work so why is it a built in requirement and must be installed for this port to work?
I can only speculate on this -
- maybe the majority of users who read pdfs have sometimes the need to print part or whole pdf (like me)
- maybe the creator team of this program decided that they need to print sometimes and they decided the way to go is cups
- maybe the porter of this application does follow the above arguments or simply did not see any sense in cutting out code he ported from the qpdfview project (and increasing his own workload considerable) only to make one OS/2 user happy while distress a lot of others 

Of course you can ask on qpdfview user or developer list this topic. But for me such discussions are as useless as a hole in the head. And fear the developers of qpdfview will see it similar. They use some *nix system where cups is standard. If I should speculate again they will say that's the way it is, take it or leave it.

which is not the answer for cleaning up old dlls. 'which -lasu libc065.dll' can only find dlls in current directory and libpath. But not the ones which are loaded by some application in theirs directory regardless if you have . in libpath or not. Btw. that's the reason why I implemented in my which port a warning message about that fact. And that's why I wrote above -
Quote
What a user needs to do for cleaning up his mess would be searching all drives for duplicates of every dll in %unixroot%/usr/lib. Tools like DataSeeker, pmseek, SearchPlus can be used for this.

FC/2 works great for that too.

Problem is too many users copied some dlls into some directories all over their system and now reap what they sow. Ways to start cleaning of a system are
- run one of the above tools at least for all dlls and dependencies listed in the readme
- double check with which -lasu all these dlls (you can use pmdll to get the list of dlls but you have to repeat this step)
- check all your programs you start automatically or manually after reboot for dlls they use and where they are placed on your system

I'd start searching for libc first. Many programs came with a libc version that was installed in the program directory. Once these are cleaned up, many problems disappear-

Another method would be reinstalling eCS WITHOUT manually changing libpath afterwards (I hate to suggest the Windoze way)

Doug Bissett

  • Hero Member
  • *****
  • Posts: 1593
  • Karma: +4/-2
    • View Profile
Re: qpdfview
« Reply #38 on: March 11, 2015, 05:46:51 am »
Quote
Now, it seems that I have a problem with PTHREAD, that I will admit I haven't got around to reporting (sorry, life got in the way).

Well, I THINK I found that one. I have CLAMAV installed, using the clamavgui package. That thing has it's own DLL library, which is down level, and never should have been there in the first place (it did contain an ols version of PTHREAD.DLL). It is not in LibPath, but it seems that if something used CLAMAV, before I tried to start AOO4, AOO4 would crash, hang, or simply reboot the system. The odd thing is, that the older version of PTHREAD didn't have the problem.

Using the OS/2 Kernel tool from X(e)Workplace, I see that there are many duplicate DLLs, and EXEs, all over the system (and that seems to only look in the paths, any others are ignored). That is made MUCH worse when a user installs RPM/YUM, because YUM keeps it's own copies of everything, but does nothing to be sure that there are no other copies anywhere.

I guess I have about two days of work, to sort that out.

QPDFView still can't find the plugin, unless it is on the boot drive.

Silvan Scherrer

  • Full Member
  • ***
  • Posts: 200
  • Karma: +1/-0
    • View Profile
Re: qpdfview
« Reply #39 on: March 11, 2015, 05:21:08 pm »

QPDFView still can't find the plugin, unless it is on the boot drive.
Does this mean the complete qpdfview has to be on your bootdrive or only some dll?
Even I can't reproduce it here, I would be interested to iron this problem out.

Here bootdrive is c: and qpdfview is on e:\somedir and it works.
Did you try to delete %HOME%/.config/Trolltech.ini after moving the dll to another location?
kind regards
Silvan
CTO bww bitwise works GmbH

Please help us with donations, so we can further work on OS/2 based projects. Our Shop is at https://www.bitwiseworks.com/shop/index.php

Doug Bissett

  • Hero Member
  • *****
  • Posts: 1593
  • Karma: +4/-2
    • View Profile
Re: qpdfview
« Reply #40 on: March 11, 2015, 09:14:56 pm »

QPDFView still can't find the plugin, unless it is on the boot drive.
Does this mean the complete qpdfview has to be on your bootdrive or only some dll?
Even I can't reproduce it here, I would be interested to iron this problem out.

Here bootdrive is c: and qpdfview is on e:\somedir and it works.
Did you try to delete %HOME%/.config/Trolltech.ini after moving the dll to another location?

I didn't move any DLLs, that I know about, except those in the QPDFVIEW directory, with the program. However, deleting %HOME%/.config/Trolltech.ini does fix the problem (I put the QPDFVIEW directory back where I want it).

This really doesn't make any sense, because the DLLs were never on the boot drive, until I moved the whole QPDFVIEW directory (including the DLLs) to the boot drive. Then, it worked, somehow (I would expect that it wouldn't, if there is something in %HOME%/.config/Trolltech.ini that needs to change when the DLLs are moved). Before I moved the directory, I had the previous version of QPDFView installed (and working), and all I did was replace the files in that same directory. Then, it couldn't find the plugin. I did put the older QPDFView back in that directory, and it worked, without messing with %HOME%/.config/Trolltech.ini.

Since there seems to be no problem with removing %HOME%/.config/Trolltech.ini, I am tempted to just delete it at every boot (perhaps every time I start QPDFView might be better). I remember having some sort of problem with that file before (probably with QPDFView), and the fix was to delete it.

Any comments?

Doug Bissett

  • Hero Member
  • *****
  • Posts: 1593
  • Karma: +4/-2
    • View Profile
Re: qpdfview
« Reply #41 on: March 11, 2015, 10:39:22 pm »
Quote
Btw. that's the reason why I implemented in my which port a warning message about that fact.

I have two versions of which.exe. 2.1.5, from Michael Greene, and 2.20 from Mentore Siesto. 2.20 doesn't follow the dot, while 2.1.5 does (but only to the directory where it is started from). It looks like 2.20 came from HOBBES. I don't know where the other one came from.

So, which which do we want to use, and where does one find it?

Quote
Problem is too many users copied some dlls into some directories all over their system and now reap what they sow.

Well, that is PART of the problem. The rest appears to be caused by developers including things in their packages that are put into the wrong place. Even the recent AOO-4111-GA-rpm.wpi package puts a bunch of DLLs (some of the ones that are now causing problems) into the AOO4\program directory, when they should be in \eCS\DLL on eCS systems, or \OS2\DLL on other OS/2 systems. Of course, if you install that stuff using YUM, they go into @UNIXROOT/usr/lib (note the *NIX location, which is placed first in LibPath). YUM also fails to remove any of those things that may be in the "old" locations, aggravating the problem even more.

The bottom line is, that the only way to get it right, without doing a LOT of manual work, is to re-install eCS 2.2 b2 (or later, I would presume), selecting to include the RPM/YUM stuff (which is installed by default, and is well hidden so you can't find the setting to avoid it), then never use anything except YUM to do updates, unless YUM does not supply what you need. Then, if you do use an alternate install procedure (ZIP, WarpIn), and YUM eventually does get around to including it, you need to go back and get rid of the old install.  You also have the problem where various packages have different "features". Apparently, the Ghostscript, supplied by YUM, won't work with CUPS, but it is required for some other package that uses it. Now, it seems that the user needs to have two (perhaps more), different, copies of Ghostscript installed, and they need some way to get each program to use the proper version. I assume that LIBPATHSTRICT would allow that, but what a PITA.

I will point out that it appears that NONE of the stuff that comes from YUM has BLDLEVEL information in it. That basically means that there is no way to verify which version of a file you actually have installed. YUM keeps a database of that information, but it isn't strictly tied to the actual file. If the file gets changed, for some reason (perhaps it got restored from a backup), YUM still assumes that you have the one that it knows about. There may be some way to verify the database, but I haven't figured it out.

Alex Taylor

  • Sr. Member
  • ****
  • Posts: 387
  • Karma: +5/-0
    • View Profile
Re: qpdfview
« Reply #42 on: March 12, 2015, 01:35:14 am »
whichdll.exe finds DLLs which are already loaded by an application. If none is loaded, it finds whichever copy would be loaded by default.

My RXUTILEX.DLL Rexx library also includes this function (Sys2LocateDLL).

Silvan Scherrer

  • Full Member
  • ***
  • Posts: 200
  • Karma: +1/-0
    • View Profile
Re: qpdfview
« Reply #43 on: March 12, 2015, 08:30:41 am »

QPDFView still can't find the plugin, unless it is on the boot drive.
Does this mean the complete qpdfview has to be on your bootdrive or only some dll?
Even I can't reproduce it here, I would be interested to iron this problem out.

Here bootdrive is c: and qpdfview is on e:\somedir and it works.
Did you try to delete %HOME%/.config/Trolltech.ini after moving the dll to another location?

I didn't move any DLLs, that I know about, except those in the QPDFVIEW directory, with the program. However, deleting %HOME%/.config/Trolltech.ini does fix the problem (I put the QPDFVIEW directory back where I want it).
I meant moving around qpdfview and those dll's like qpdfpdf.dll.
Qt remembers from where it loaded Qt dll's. And as qpdfview is a Qt application Qt knows from where it loaded the qpdfpdf.dll as example.
So if this dll gets moved to another location, Qt will not load it (beside it's in the bootdrive it seems).
This is a general Qt feature and has nothing to do with our port. Even we fixed/changed some stuff we think was ugly there already.

So deleting the ini file at every boot doesn't hurt, but makes the first start of a Qt app slower. And I don't think this is needed. But when you decide to have a QT app which was installed to move to another location, I would delete the file.

I hope this clears some questions here.
kind regards
Silvan
CTO bww bitwise works GmbH

Please help us with donations, so we can further work on OS/2 based projects. Our Shop is at https://www.bitwiseworks.com/shop/index.php

Doug Bissett

  • Hero Member
  • *****
  • Posts: 1593
  • Karma: +4/-2
    • View Profile
Re: qpdfview
« Reply #44 on: March 12, 2015, 04:09:11 pm »
Quote
I meant moving around qpdfview and those dll's like qpdfpdf.dll.

Yes, I know that. The DLLs were in the QPDView directory, on my W: drive. The previous version of QPDFView was working, with no trouble. Then, I simply replaced the files, in that directory, with the new files (a one for one change). The new QPDFView could not find the DLL. When I moved the whole directory, including the DLLs, to the boot drive C: (just something to try), it started to work. From what you say, there must be some mechanism that notices a changed file, and doesn't recognize that it is the same file name. I have no idea why it would work when it was on the boot drive.

Quote
So deleting the ini file at every boot doesn't hurt, but makes the first start of a Qt app slower. And I don't think this is needed. But when you decide to have a QT app which was installed to move to another location, I would delete the file.

Whatever it does, I don't notice slower startup with anything. I did not move the location, until after it was broken. All I did was replace the DLLs. Perhaps the install instructions need to insist that a user should just delete the ini file (make it one of the steps, rather than an afterthought), for every QT app install (although I don't think I have had a problem with anything other than QPDFView, even after moving things). Better would be for the program to reinitialize itself, if it can't find whatever it is looking for. Unfortunately, I did not keep the INI file for comparison to the one that works. I may have it saved in a backup, somewhere, if I can find it.