• Welcome to OS2World OLD-STATIC-BACKUP Forum.
 

News:

This is an old OS2World backup forum for reference only. IT IS READ ONLY!!!

If you need help with OS/2 - eComStation visit http://www.os2world.com/forum

Main Menu

odin 0.8.3

Started by mmarquardt, 2012.02.21, 01:57:30

Previous topic - Next topic

mmarquardt

I downloaded and unzipped libc064_test_1.zip.  It contains an apparently altered libc064.dll file.  I am not sure what to do with this file.  I do not want to replace my working libc064.dll file with this testing file.  The accompanying readme file indicates that the altered libc064.dll file is for testing purposes only.  Any instruction is appreciated.  Thanks.

Pete

Hi

You *do* want to replace the original libc064.dll file with the test version as it seems to provide better backwards capability with apps that require libc063.dll.

Regards

Pete

StefanZ

Hmmm, interesting.

No matter what I do, each time I'm trying to run something under Odin I get this error:

Can't load/find kernel32.dll (rc=2, module STDCPP)  :(

Pete

Hi StefanZ

Have you installed the following packages?

ftp://ftp.netlabs.org/pub/gcc/libc-0.6.4-csd4.wpi

ftp://ftp.netlabs.org/pub/odin/test/libc064_test_1.zip

ftp://ftp.netlabs.org/pub/gcc/gcc4core-1_2_1.wpi


Warning! The above urls may get corrupted by os2world.com adding http:// to the front and removing the ":" after the starting "ftp". Not sure why os2world does this but wish they would sort it out...


The STDCPP.DLL file is in the gcc4core-1_2_1.wpi package which will not install if libc-0.6.4-csd4.wpi is not installed. The libc064_test_1.zip contains a later, test libc064.dll file which seems to work better with apps needing libc063.dll.


Regards

Pete

mmarquardt

Thanks for the information about the libc064.dll file.  The new file should be placed in the ecs\dll subdirectory, I assume.  Is that correct?  What about having both the libc063.dll and the libc064.dll file in the same ecs\dll subidrectory?  Or will odin just ignore the libc063.dll file?  Thanks again for all your help and information.

ivan

Yes, just add it in with all the other DLLs.  I have libc061,  062, 063, 064, 064x and a few others as well as 12 gcc'xxx' dlls and everything works without problems so far.

mmarquardt


rudi

Quote from: mmarquardt on 2012.02.24, 00:01:35
Thanks for the information about the libc064.dll file.  The new file should be placed in the ecs\dll subdirectory, I assume.  Is that correct?  What about having both the libc063.dll and the libc064.dll file in the same ecs\dll subidrectory?  Or will odin just ignore the libc063.dll file?  Thanks again for all your help and information.

The concept of the libc versioning is that an officially released higher number package (064) will contain all (officially released) lower numbered DLLs (063, 062, 061, 06). However, these lower numbered DLLs are only forwarders to the main (higher number) DLL. Thus, if you install 064 in the way it is intended, applications linked against earlier versions of libc (063, 062, 061, 06) will effectively use 064. In some situations (plugin based software with modules from different different vendors) it even is essential, that only a single version of libc is used.

ivan

That may be the theory rudi but in practice it doesn't always work like that.

ivan

aschn

Quote from: ivan on 2012.02.24, 13:25:41
That may be the theory rudi but in practice it doesn't always work like that.

Then there exists a cause. Your practice vs. theory theory won't help then.

Andreas

mmarquardt

It seems to me that it would be desirable if the newly released versions of odin would contain, or at the very least be accompanied by, easily installed versions of the required latest dependencies.  I think it would be nice if it worked in a manner similar to that of the debian linux package manager, so that when a new package is installed, all the required dependent packages are also installed.  I am aware that there is an rpm/yum package manager for installing odin.  I tried to use it to install odin 0.8.2, but it seemed very confusing to use, and I could not get it to successfully install odin 0.8.2.  The warpin package manager seems to work pretty well when it works.  Any comments are appreciated.  Thanks.

DougB

QuoteIt seems to me that it would be desirable if the newly released versions of odin would contain, or at the very least be accompanied by, easily installed versions of the required latest dependencies.

There has been a LOT of discussion about using a *NIX type of installer (see the RPM/YUM thread). Believe me, you really don't want multiple copies of basic system DLLs, or things like ODIN, at various levels, on your system, in different places. That is a phenomenon known as "DLL HELL". It is bad enough as it is since we need to maintain multiple versions of various DLLs. The only reasonable way to be able to manage that nonsense is to keep them all in one place, and have only one copy of each. The eComStation group has decided to put those things into the \eCS\DLL directory (which makes sense). Since the older versions of OS/2 don't have that directory, the files should go into \OS2\DLL. Any other copies of system DLLs  (GCC Libc) that exist anywhere else should be removed, or moved to one of those locations. There is nothing worse than trying to figure out why a program quit working, only to find that some other program has added a DLL somewhere where it isn't supposed to be (like in the ODIN directory structure). We still have the problem where a defective DLL gets produced (like the original Libc064.dll), and that is made worse by the forwarder DLLs that link calls to earlier versions to the defective one. That breaks a lot of things, but it is not as difficult to figure out what to back out, when it happens.

True, the whole thing is not "perfect", but nobody has yet come up with a better solution. It would help if those who have been packaging the GCC, and Libc, dlls into WarpIn packages would do it consistently. The current packages overlap, and conflict with each other sometimes, and that doesn't make it easy for those who package other things in WarpIn to be able to verify that prereqs are installed, or not.

You also need to remember, that these large install packages eat internet bandwidth, for those who are limited, and are pretty well unusable by those who are stuck with dial up connections. No package should ever contain anything except the package itself. Your proposal to just add the "required parts" adds large amounts of data to these downloads, that should not be necessary, especially if the user already has the required packages.

QuoteThe warpin package manager seems to work pretty well when it works.

It does, but many people who package things with WarpIn do not do it properly. For instance. The ClamAV 0.97.3 package does not create the ClamD icon properly. It leaves out the program name in the icon. It also just adds a new UNIXROOT to your CONFIG.SYS, which can be deadly, and is completely unnecessary, since ClamAV 0.97.3 doesn't even use UNIXROOT.  ClamAVGUI does not make use of the information available about where ClamAV gets installed (when installed by WarpIn). One that does work pretty well, is the PMMail installer, but it isn't perfect either. Another problem with WarpIn is that some people just don't want to use it. That is okay , but in most cases, they had better know what they are doing, or they can create problems for themselves. The same is true of RPM/YUM, but RPM/YUM will create it's own problems for you (when I first installed it, SAMBA quit working because RPM/YUM decided that UNIXROOT should point to a different place). You can extract the files from either packager, and put them where you want them. Then, you can spend more hours figuring out why they don't work. At least extracting files from a WarpIn archive is as simple as extracting them from a ZIP file (use WPIView). When you try to extract things from an RPM package, you may find a lot of stuff that has nothing to do with the part that you want, then you need to sort that mess out.

I expect that we will end up using multiple installers, eventually (actually, we already do). RPM/YUM needs a LOT of work to make it user friendly, but it seems that those who are porting Linux software seem to think it cuts down on the work required to do the ports (it probably does, but it sure increases the work required by users). It has been my experience, that most Linux ports are not useful anyway, but others probably disagree. If those who are working on RPM/YUM would put their time toward fixing more basic problems, we would all be better off.

CDRWSel

Yes, seen after I got one feedback telling me about these problems... This is why feedback is very important.

The 0.97.3 wpi is going to be corrected to correctly add the program path under created clamd icon and no more add copy of unixroot into config.sys

Cheers/2
Remy   

CDRWSel

ClamAV 0.97.3 WPI corrected today (you can get new package)
ClamD icon has now the program fullpath and no UNIXROOT checked/added into config.sys due this build do not need it.

Cheers/2
Remy

mmarquardt

Thanks for all the information about package installation.  The installation situation seems pretty messy.  Still, standardization and easy usability seem desirable.  All easier said than done.