(Sorry to be a little talkative today, but I will easily refute everything.)
Les Mikesell wrote:
> If you are moving binaries to any other machine, you are likely to
> have odd failures if you don't carefully control the libraries in the
> build environment.
The linker doesn't and cannot link 64-bit objects to 32-bit libs.
There's nothing else. Include files/etc. that are duplicated in 32-bit
RPMs must be identical otherwise rpm doesn't install them together.
> If you aren't moving them to some other machine,
> then you rarely if ever need anything but the native libraries and
> development header set.
That's the basic use case anyway: A user compiles his stuff on the
frontend of the cluster and then submits his job.
> The libraries are useful for 3rd party binary apps, but why build a
> 32bit app yourself if you are going to run it in a 64bit environment?
Three examples I have already given. To repeat one: a user has a code
base that is not 64-bit clean? What am I to do? Tell him to f*******,
fix it myself for him, or what?
> I recall at least a couple of update conflicts/failure in the 5.x line
> caused by having 32bit versions of things installed on a 64bit host.
> Didn't those affect you?
Also already answerded: They forgot to copy the 32-bit updates to the
64-bit updates repo. In one case there was a real bug. This happend only
a couple of times so far in the 5.x time frame. So what? There where
other bugs as well.
> And there is always the extra time wasted
> doing updates to libraries and programs you don't ever use.
They update with everything else, there's no bandwidth limitation for
these machines and the discs are big enough. (The 'everything' I
described shortly elsewhere + a lot of extras totals to ~16 GB of disc
space. That's nothing.)
-Michael
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos
