OS/2, eCS & ArcaOS - Technical > Applications

Odin

<< < (3/5) > >>

Doug Bissett:
I should have mentioned, that the package that you installed is the older Libc064 developer package. That is not what you really want, although it probably contains the DLL that you need. I would suggest removing that stuff from the Mozilla folders. You do NOT want more than ONE each of those DLLs, or you might get into a situation known as "DLL HELL".

lmotaku:
Wait, I didn't think it were possible to be in a worse Dll hell than Windows? You are probably referring to putting dll's in C:\ecs\dll ? or C:\OS2\dll?
Edit: sorry, it's 1am, haha. Case of the Monday.. Tuesday.. damn it. I understand now. The Library should be installed properly, but I've already installed GCC4.3.3 as a wpl. (Properly I think), it's all good. Just happened to use the first google response for libc064. Installed those two wpls and removed all dll files I manually put in.

Dave Yeo:
Windows is worse for DLL hell due to using C++ but it can still happen with OS/2.
x:\os2\dll or x:\ecs\dll aren't too bad of choices, you can also have a dedicated directory for DLLs by adding a directory to the LIBPATH statement in config.sys. OS/2 uses LIBPATH to find DLLs. You should also put the mozfntcfgft DLLs in the same place as other things are starting to use them. Most people have one partition for the operating system and other partitions for programs etc.
Really FF 10.0.12 should depend on libc065 as that is what I linked it against, I think the libc064 dependency comes from the statically linked GCC library as GCC 4.4.6 was built with libc064.

--- Quote ---I did both C:\home\default\Mozilla\Firefox and C:\programs\firefox I'm thinking only one of these locations actually need it, and that would(might be) the first one.
--- End quote ---

c:\programs\firefox will work if LIBPATH contains a dot (usually does), the profile directory will not work.

Doug Bissett:

--- Quote from: Larry on March 19, 2013, 06:19:08 am ---Wait, I didn't think it were possible to be in a worse Dll hell than Windows? You are probably referring to putting dll's in C:\ecs\dll ? or C:\OS2\dll?
Edit: sorry, it's 1am, haha. Case of the Monday.. Tuesday.. damn it. I understand now. The Library should be installed properly, but I've already installed GCC4.3.3 as a wpl. (Properly I think), it's all good. Just happened to use the first google response for libc064. Installed those two wpls and removed all dll files I manually put in.

--- End quote ---

Remember that windows, and OS/2 are from the same roots.

It has become customary for eCS users to put the base OS/2 DLLs into \OS2\DLL, and to put additional "system wide" DLLs into \eCS\DLL. OS/2 (non-eCS) does not have a \eCS\DLL directory, so they put additional "system wide" DLLs into \OS2\DLL. It is only a way to manage the location, and make sure that duplicates don't exist. They can be anywhere, as long as the location is in LIBPATH in CONFIG.SYS, and the location is permanently available to the system.

It is also customary, but not essential, to keep program specific DLLs somewhere in the program directory. The dot ".;" entry in LIBPATH says to look in the current path (usually the Working directory, as defined in the program icon properties), for DLLs. That way, the DLLs can be found without having to put that specific path into the LIBPATH statement. Also, be aware that some program installers include things like Libc064.DLL (the real one), and they need to be removed so you don't have duplicates.

"DLL HELL" can be the result, if you put something like Libc064.DLL (the real one, not the forwarder) into the program directory (for instance). The program will probably work okay, but that may depend on which Libc064.DLL gets loaded first. Once those things get loaded, they usually never get released, and any other program that needs them just uses what is already loaded. So, sometimes, you may be using the forwarder, and sometimes the real thing. It shouldn't make any difference in that case (but it can). It gets more complicated when you try to run Firefox, and Thunderbird, at the same time. They each have a common DLL name, but the actual DLLs are different. That requires other techniques to work around. The program RUN! is the best answer. Search for RUN! at HOBBES http://hobbes.nmsu.edu/. I think the instructions should be good. You can also look up LIBPATHSTRICT which changes the rules, but needs to be used properly, or other problems can be caused.

Andy Willis:
Beside the Libpath there is also the beginlibpath and endlibpath which can be set (though are not technically environment variables) before launching an application. 

Navigation

[0] Message Index

[#] Next page

[*] Previous page

Go to full version