This link is in 
/usr/lib64/gcc/x86_64-suse-linux/4.1.2/libgcc_s.so 
now.  This works ok with the gcc33 packages on the openSUSE build-service.  I suggest we simply drop compat-g77 from the compat-libstdc++ package.

*** Bug 229586 has been marked as a duplicate of this bug. ***

*** Bug 231713 has been marked as a duplicate of this bug. ***

*** Bug 235256 has been marked as a duplicate of this bug. ***

This is fixed in the openSUSE 10.2 release as it doesn't contain compat-g77 anymore.  Instead you can grab gcc33 from

http://repos.opensuse.org/devel:/tools:/gcc/openSUSE_10.2/

(In reply to comment #5)
> This is fixed in the openSUSE 10.2 release

openSUSE 10.2 _does_ contain compat-g77:

http://ftp.estpak.ee/pub/suse/opensuse/distribution/10.2/repo/oss/suse/i586/compat-g77-3.3.5-38.i586.rpm

Therefore, it's a WONTFIX for 10.2 and FIXED for future releases only.

For future duplicate reports, the workaround on x86 is:

ln -s /lib/libgcc_s.so.1 /usr/lib/libgcc_s.so

On x86_64 you additionally need:

ln -s /lib64/libgcc_s.so.1 /usr/lib64/libgcc_s.so

The reason why these symlinks are not present by default is that they break parallel installation of multiple gcc versions.

Oh right, it's built from the compat-libstdc++ sources.  Reopening...

... to mark as WONTFIX.

(In reply to comment #8)
I didn't like what was happening to bug 235256, and was composing a message in my head overnight.  Comment #6 above helps me to understand.  Yes, links can be done, but that is very tedious to do on a bunch of machines of different architectures. 

I need some clarity.  If I add the symlinks, will that break the gcc4/gfortran installation, because there are now multiple versions?  Actually. I have installed both gcc and gcc41 (and related double packages).  Would that parallel installation be broken?  Should I remove the ...41 packages?  If adding symlinks breaks something else, then it seems to me that 10.2 is broken for users in one way or another.

Would it be possible to update and redistribute compat-g77 with the symlink(s) in the .../3.3/5 directory?  Actually, that works for an i586 system, but there would be problems for x86_64 systems that allow both 32- and 64-bit compilations.

I discovered the active bug 127745, and commented there that keeping a fully functional g77 option is still important for awhile.  'WONTFIX' is not good.

Usually we do not provide gcc maintainance updates, but of course compat-g77 is
special here.  Still the packages provided by the openSUSE build service provide
a working SLES9 based gcc, g++ and g77.

(In reply to comment #10)
I agree with you that compat-g77 is special.  You and I probably also agree that it would be nice not to need it anymore.  But...

I looked at the gcc33 files that were referred to.  First, very few people will know about the SuSE build site.  It is nice, but I just now learned about it here.  Even if someone finds it, rummaging through it to find gcc33 is perplexing.  And that is when someone, somehow, actually learns about a gcc33 and the location, when they no longer have a 'g77' command.  I downloaded the i586 set and thought I would try it. But in doing preventive checking in advance, I found that two files installed by the gcc41 set would be overwritten:
1) libgcc33-3.3.3-27.4.i586.rpm overwrites /lib/libgcc_s.so.1
2) libstdc++33-3.3.3-27.4.i586.rpm changes the link /usr/lib/libstdc++.so.5 
      from ...libstdc++.so.5.0.7 to ...libstdc++.so.5.o.6 .
Naturally, I didn't do it.  Others might and then get into troubles.

I didn't get clarity to my questions in #9.  So, according to #6, the symlinks were removed because they break parallel installations and, now, the workaround is to put in the symlinks.  Doesn't seem logical.  Well, that might depend on where the symlinks are placed.  If they are put in as in 10.1, something will probably break.  But if added to the .../3.3.5 directory, all should be OK.  (For x86_64, they can go in ...3.3.5 and in ...3.3.5/32.)  They are self-contained in conpat-g77, and do not affect anything else.  There is no need to 'maintain' compat-g77; just keep it in the distribution.  No work involved.
Advantages:
1) Users have a functional 'g77' out of the box.  (The gcc33 stuff does not give 
   'g77', but 'g77-3.3'.  Easy to fix, but it might take awhile to discover.)
2) Not dead in the water because the build system is not known about, and/or 
   is tough to navigate.
3) No downloads and individual installations by hand on multiple machines.
4) No complaints to bugzilla.
5) No lost time and frustration in tracking things down.  Increased happiness.
6) Solves a real problem for a number of people.  No harm to others.
7) Unhindered productivity, surely a good thing.
8) More...

I don't see a down side.  It looks to me like a winner for everyone.  I'm not the original author so I won't 'reopen,' but I do object to 'wontfix.'

Yes, we can easily fix compat-g77 by putting the missing symlink in the 3.3.5/...
directory.

Last time I checked the gcc33 packages do not overwrite files from the gcc41
package - they for sure do obsolete compat-g77 and compat-libstdc++ (the latter
with a slightly older version).

I'm re-opening - but don't expect anything too soon.

approved for 10.2 update:    	 MaintenanceTracker-7958

(In reply to comment #12)
Very good.  Thank you.  I can confirm that the symlinks I suggested work for both i586 and x86_64 systems.  The links referred to in Comment #6 would go into the ...3.3.5 directory.  In addition, the following links are needed for the ...3.3.5/32 directory:
  ln -s /lib/libgcc_s.so.1 libgcc_s.so
  ln -s libgcc_s_32.so libgcc_s.so.1
  ln -s /lib/libgcc_s.so.1 libgcc_s_32.so
(This information is for those who might need it before the rpm is available.)
In fact, my check on a x86_64 system was for a 32-bit (-m32) compile/link.

released

*** Bug 255419 has been marked as a duplicate of this bug. ***