Redhat 7.3 client version?

[Brian the Fist]

Ok, I am thinking of discontinuing the redhat 6.2 gcc version of the client and replacing it with a RedHat 7.3 Intel Linux gcc version. The main question is are there any objections?

The problem is binaries built on RH7.3 will not work on systems with glibc from before about RH7.0. (Im not sure WHY it is not backwards compatible, this seems like poor design to me...) So will we be cutting off any users by doing this?

I do NOT wish to have three Intel Linux versions so that is not an option. Please vote only if you USE the Linux client
Note that the Intel icc linux client will remain for redhat 7.1, this is unaffected for now.

[dnar]

I for one plan to use the 6.2 gcc version on disk-less netbooting nodes, and my workstations will soon be upgraded to RedHat 8.0 (when it arrives), so my vote would have been to maintain 3 versions.... (I have not voted on this poll BTW).

I respect your wish not to maintain 3 client builds, if the gcc 6.2 build goes, I'll just work on a different project on those disk-less nodes.

[Brian the Fist]

Just in case there's some Linux gurus reading this - IS there some way to make the binary work on both RedHat 6.2 and 7.3 without having two separate binaries? Is it impossible or is there a great disadvantage in doing so?

[IronBits]

Excuse my ignorance,
How does RedHat 6+ or 7+ figure in with Mandake 8.2 ?
Same as 7+ ?

[Kosh]

I believe Mandrake 8.2 and RH 7.2-7.3 have approximately the same set of packages. (glibc for Mandrake 8.2 is 2.2.4 same as RH7.3)

I'm not sure how much this would help, but could you post a simple test program in RH 7.3 intel gcc so we could see if it collides with other distros? (Or maybe just checking glibc versions is enough?)

From my own experience I can say that the rh7.1 build works on Slackware 8 and 8.1.

Slack 8.1 = glibc 2.2.5, RH7.3=2.2.4 so I think I'll vote for the RH7.3 build.

Howard: thanks again for the effort you are putting into all of this!

edit: brackets and capitalization

[devzero]

Mr Fist:
Its not portable because of the dynamic depedancy of libc and libtphread.

ldd foldtrajlite
./foldtrajlite: /lib/libc.so.6: version `GLIBC_2.2' not found
./foldtrajlite: /lib/libpthread.so.0: version `GLIBC_2.2' not found
If you were to statically link the entire program it would be fine. The disadvantage is:
larger executable.
larger memory requirement.

If you use the intel compiler with the older libc and pthread, I think the binaries would be upwardly
compatible.

I have several machines still running older distributions which would now exclude them.

[muttley]

I only have Redhat 7.2 and do not know how to upgrade to 7.3 or higher and at present my other machine is down that can do an CD/RW ISO though I have never done an ISO. I use an AMD 1700+XP machine. As for this Linux machine it is a learning machine on how Linux works. I had to ask someone what program to put on this machine and right now poking around I couldn't tell you much about this foldit program as from the command line and inside the subfolder there seems to be no clues as to version or whatever. I'm burried with other work and as long as I get assistance will keep plogging along.
muttley
PS as for voting didn't and cant see where to at present reply.

[Jodie]

Yuppers - staticly linking latest atleast glibc should do it.

I had plans to use the client for burn-in on the settops (6.2 lightened) - but they're not all that speedy - so it doesn't matter much...