OS2World OLD-STATIC-BACKUP Forum

OS/2 - Technical => Applications => Topic started by: mmarquardt on 2012.02.21, 01:57:30

Title: odin 0.8.3
Post by: mmarquardt on 2012.02.21, 01:57:30
I have not been able to install odin 0.8.3.  I tried the zip package and the WarpIn package with the same failed result.  When pe.exe is run, there is an error about not finding stdcpp in kernel32.  Odin 0.8.2 does not work for me either, memory problems, if I recall correctly.  Does anyone know about how to get odin 0.8.3 to work?  I am using ecomstation 2.1.  Thanks.
Title: Re: odin 0.8.3
Post by: dryeo on 2012.02.21, 02:19:25
You need to install gcc4core-1_2_1.wpi which I got from the same page as the new Flash. There should be one on netlabs somewhere, possibly the odin or gcc directories.
Title: Re: odin 0.8.3
Post by: mmarquardt on 2012.02.21, 02:26:42
Thanks.  I have gcc446.dll installed in the system32 subdirectory, but that does not seem to help.  Is there more to the gcc4core-1_2_1.wpi file?
Title: Re: odin 0.8.3
Post by: DougB on 2012.02.21, 06:56:05
QuoteIs there more to the gcc4core-1_2_1.wpi file?

Yes.
Title: Re: odin 0.8.3
Post by: DougB on 2012.02.21, 07:04:09
QuoteI have gcc446.dll installed in the system32 subdirectory

Why would you put it there? The GCC, and LIBC dlls are system wide, not just for ODIN. Many programs use them. It is strongly suggested that you put them into a common system directory such as <boot drive>:\eCS\DLL (default for eComStation), or <boot drive>:\OS2\DLL (default for other versions of OS/2). Then, make sure that there are no other copies anywhere on your system. That makes it a LOT easier to keep yourself out of trouble.
Title: Re: odin 0.8.3
Post by: dryeo on 2012.02.21, 10:09:44
After installing the libc package you should probably install this, http://ftp//ftp.netlabs.org/pub/odin/test/libc064_test_1.zip (http://ftp//ftp.netlabs.org/pub/odin/test/libc064_test_1.zip)
Title: Re: odin 0.8.3
Post by: mmarquardt on 2012.02.21, 16:22:08
Yes, thanks, the dll files should all be in the right places for system use, but they should also work for odin if placed in the odin\system32 subdirectory?  Odin 0.7.1, I think, is installed and working on my system, and the odin test runs correctly as does notepad from windows 2000.
Title: Re: odin 0.8.3
Post by: Andi on 2012.02.21, 16:38:58
Quote from: mmarquardt on 2012.02.21, 16:22:08
Yes, thanks, the dll files should all be in the right places for system use, but they should also work for odin if placed in the odin\system32 subdirectory?  Odin 0.7.1, I think, is installed and working on my system, and the odin test runs correctly as does notepad from windows 2000.
dlls needed for OS/2 apps have to be in libpath or in current dir. OS/2 apps do not need dlls from \system32 but win apps do. So it does not make any sense to me putting OS/2 dlls into \system32. Win dlls needed for win apps that should run via odin can have their dlls in \system32 as this is the case very often with real Win installations. Win apps running via odin find win dlls in this order - exe dir, current dir, windows system dir (where kernel32.dll resides), windows dir (from odin.ini) and PATH (according Dimitry at #netlabs this day). So putting \system32 to PATH (not LIBPATH) does make sense.

HTH
Title: Re: odin 0.8.3
Post by: mmarquardt on 2012.02.22, 01:41:27
Thanks for the infomation about how odin finds dll files.  According to your information putting the dll files in the odin\system32 subdirectory from which pe.exe is run should work.
Title: Re: odin 0.8.3
Post by: ivan on 2012.02.22, 10:59:31
Simple answer - no.

The DLL is not a windows DLL it is an OS/2 DLL and in your case should be in ecs\dll or os2\dll. 

The basic rule of thumb is that windows/odin files go in the odin\system32 dir, OS/2 eCS system files go in the OS/2 eCS directory structure.

ivan
Title: Re: odin 0.8.3
Post by: mmarquardt on 2012.02.22, 18:59:31
Okay, thanks.  I will try moving all these dll fies into ecs\dll and see if odin works.
Title: Re: odin 0.8.3
Post by: mmarquardt on 2012.02.22, 19:50:23
Well, I moved what I thought were the appropriate gcc 335 and gcc 446 dll files into ecs\dll, but odin still does not work.  I also tried installing gcc4core-1_2_1.wpi, but warpin complains of missing klibc\libc 0.6 Runtime \0\6\4\0 files or packages that I thought I had installed using libc-0_6_3-csd3.wpi.  I see that the gcc4core package contains the stdcpp.dll file that I am missing, but somehow I cannot manage to get the right files in the right places for odin 0.8.3 to run.  Any help is appreciated.  Thanks.
Title: Re: odin 0.8.3
Post by: RobertM on 2012.02.23, 01:01:31
Supposedly, it is in this package:

ftp://ftp.netlabs.org/pub/gcc/libc-0_6_3-csd3.wpi
Title: Re: odin 0.8.3
Post by: Pete on 2012.02.23, 01:23:06
Hi

Quote from: mmarquardt on 2012.02.22, 19:50:23
Well, I moved what I thought were the appropriate gcc 335 and gcc 446 dll files into ecs\dll, but odin still does not work.  I also tried installing gcc4core-1_2_1.wpi, but warpin complains of missing klibc\libc 0.6 Runtime \0\6\4\0 files or packages that I thought I had installed using libc-0_6_3-csd3.wpi.  I see that the gcc4core package contains the stdcpp.dll file that I am missing, but somehow I cannot manage to get the right files in the right places for odin 0.8.3 to run.  Any help is appreciated.  Thanks.


You might notice that libc063 and libc064 are not the same package - based on the filenames involved  :-)

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

Install gcc4core-1_2_1.wpi

Then update the libc064 package with the contents of ftp://ftp.netlabs.org/pub/odin/test/libc064_test_1.zip

If you installed odin from a ZIP package then it is necessary to run odininst.exe in the odin\system32 directory


Regards

Pete
Title: Re: odin 0.8.3
Post by: mmarquardt on 2012.02.23, 16:36:08
After downloading and installing ftp://ftp.netlabs.org/pub/gcc/libc-0.6.4-csd4.wpi and then installing gcc4com-1_2_1.wpi, odin 0.8.3 works.  Thank you for providing the link to the libc-0.6.4-csd4.wpi file and instruction to then install gcc4core-1_2_1.wpi.  The odin test program that I had installed is still linked to odin 0.7.1 that was also previously installed.  I have not yet tried updating the libc064 package with the contents of ftp://ftp.netlabs.org/pub/odin/test/libc064_test_1.zip, but I will try that next and then run odininst.exe from the odin\system32 subdirectory.  I expect that will also work.  Thank you for your help.
Title: Re: odin 0.8.3
Post by: mmarquardt on 2012.02.23, 17:49:25
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.
Title: Re: odin 0.8.3
Post by: Pete on 2012.02.23, 19:01:25
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
Title: Re: odin 0.8.3
Post by: StefanZ on 2012.02.23, 22:53:09
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)  :(
Title: Re: odin 0.8.3
Post by: Pete on 2012.02.23, 23:22:24
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
Title: Re: odin 0.8.3
Post by: 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.
Title: Re: odin 0.8.3
Post by: ivan on 2012.02.24, 02:17:13
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.
Title: Re: odin 0.8.3
Post by: mmarquardt on 2012.02.24, 05:27:06
Okay. Thanks.
Title: Re: odin 0.8.3
Post by: rudi on 2012.02.24, 08:58:13
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.
Title: Re: odin 0.8.3
Post by: ivan on 2012.02.24, 13:25:41
That may be the theory rudi but in practice it doesn't always work like that.

ivan
Title: Re: odin 0.8.3
Post by: aschn on 2012.02.24, 21:03:38
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
Title: Re: odin 0.8.3
Post by: mmarquardt on 2012.02.24, 23:54:34
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.
Title: Re: odin 0.8.3
Post by: DougB on 2012.02.26, 18:33:12
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.
Title: Re: odin 0.8.3
Post by: CDRWSel on 2012.02.26, 19:49:02
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   
Title: Re: odin 0.8.3
Post by: CDRWSel on 2012.02.26, 23:42:05
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
Title: Re: odin 0.8.3
Post by: mmarquardt on 2012.03.01, 23:36:17
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.