I'm currently discovering the true pain of 64 bit redhat boxes.  That
pain being that the 64 bit and 32 bit versions of everything -
specifically shared libraries - live in different packages, and for
typical installs on a 64bit machine the 32bit packages will not be
installed at all.  This makes life ever so interesting if you have
64bit boxes on which people want to run 32bit applications.

So I had a look at some Solaris machines and found what I expected,
which is that the 32 and 64bit versions of shared libraries (well, all
the shared libs I looked at in my exhaustive research which was
approximately libc.so...) belong to the same package.

I'm pretty naive about Solaris packages - I know how to drive the
install tools etc and have made packages on occasion, but I've never
really read the manuals properly.  Is it always the case that this
should be true for packages, so I should never have to worry about
whether there are 32 or 64 bit versions of things?  Does the package
make a decision at install time what to install, or does it always
install all versions of things even when they mght not be needed (I'm
thinking of installs on 32bit x86 boxes nowadays I suppose, but
earlier on this must have been true for SPARC too)?

Thanks

--tim

On May 24, 12:34 pm, Tim Bradshaw <tfb+goo...@tfeb.org> wrote:
> I'm currently discovering the true pain of 64 bit redhat boxes.  That
> pain being that the 64 bit and 32 bit versions of everything -
> specifically shared libraries - live in different packages, and for
> typical installs on a 64bit machine the 32bit packages will not be
> installed at all.  This makes life ever so interesting if you have
> 64bit boxes on which people want to run 32bit applications.
>
> So I had a look at some Solaris machines and found what I expected,
> which is that the 32 and 64bit versions of shared libraries (well, all
> the shared libs I looked at in my exhaustive research which was
> approximately libc.so...) belong to the same package.
>
> I'm pretty naive about Solaris packages - I know how to drive the
> install tools etc and have made packages on occasion, but I've never
> really read the manuals properly.  Is it always the case that this
> should be true for packages, so I should never have to worry about
> whether there are 32 or 64 bit versions of things?  Does the package
> make a decision at install time what to install, or does it always
> install all versions of things even when they mght not be needed (I'm
> thinking of installs on 32bit x86 boxes nowadays I suppose, but
> earlier on this must have been true for SPARC too)?

Are there _still_ 32bit x86 around? SPARC ended the 32bit line in 1997
or so... ;-)

For your question, I have no sure answer. I think it's fare to say
that you will never have this kind of problems on Solaris but I have
nothing backing that up.

Tim Bradshaw <tfb+google@tfeb.org> writes:

>So I had a look at some Solaris machines and found what I expected,
>which is that the 32 and 64bit versions of shared libraries (well, all
>the shared libs I looked at in my exhaustive research which was
>approximately libc.so...) belong to the same package.

This used to be different in the time that 64 bit Solaris was
option for SPARCv9 systems (because of the small disks in old
systems).

It wasn't until Solaris 10 that we reversed that and added all
64 bit objects to the corresponding 32 bit packages.
(This was before AMD64 support was added; build 34 of S10, vs b70
for AMD64)

>I'm pretty naive about Solaris packages - I know how to drive the
>install tools etc and have made packages on occasion, but I've never
>really read the manuals properly.  Is it always the case that this
>should be true for packages, so I should never have to worry about
>whether there are 32 or 64 bit versions of things?  Does the package
>make a decision at install time what to install, or does it always
>install all versions of things even when they mght not be needed (I'm
>thinking of installs on 32bit x86 boxes nowadays I suppose, but
>earlier on this must have been true for SPARC too)?

No, packages are agnostic about the content and they don't care.

Sun used to ship 32 bit and 64 bit packages for everything and now
we only ship one package.

Some vendors still ship the split device driver packages, even for
Solaris 10.

And even with the split packages, the split was typically as
follows:

	- SUNWfoo		32 bit binaries *AND* all configuration files
	- SUNWfoox		64 bit binaries ONLY

but some vendors ship essentially a 32 bit version of everything and a
64 bit version of the package (SysKonnect's skge driver is one example)

Casper
-- 
Expressed in this posting are my opinions.  They are in no way related
to opinions held by my employer, Sun Microsystems.
Statements on Sun products included here are not gospel and may
be fiction rather than truth.

"Thommy M." <thommy.m.malmstrom@gmail.com> writes:

>Are there _still_ 32bit x86 around? SPARC ended the 32bit line in 1997
>or so... ;-)

Tons; are they still being sold?  Yes (VIA C3 and C& are still 32 bit).

And the initial Intel "Core"  processors were also all 32 bit.
(Apple went from 64 bit power to 32 bit Intel)

Sun also prefers to ship only one release of Solaris for x86/amd64:
a choice of 32 or 64 bit kernel (default to the higest the platform
supports) and a mostly 32 bit userland (but full complement of 64 bit
libraries).  The 32 bit userland can be shared between 32 and 64 bit
as the 64 bit kernel can easily deal with both.

Casper
-- 
Expressed in this posting are my opinions.  They are in no way related
to opinions held by my employer, Sun Microsystems.
Statements on Sun products included here are not gospel and may
be fiction rather than truth.

Tim Bradshaw a =E9crit :
> I'm currently discovering the true pain of 64 bit redhat boxes.  That
> pain being that the 64 bit and 32 bit versions of everything -
> specifically shared libraries - live in different packages, and for
> typical installs on a 64bit machine the 32bit packages will not be
> installed at all.  This makes life ever so interesting if you have
> 64bit boxes on which people want to run 32bit applications.
>
> So I had a look at some Solaris machines and found what I expected,
> which is that the 32 and 64bit versions of shared libraries (well, all
> the shared libs I looked at in my exhaustive research which was
> approximately libc.so...) belong to the same package.
>
> I'm pretty naive about Solaris packages - I know how to drive the
> install tools etc and have made packages on occasion, but I've never
> really read the manuals properly.  Is it always the case that this
> should be true for packages, so I should never have to worry about
> whether there are 32 or 64 bit versions of things?  Does the package
> make a decision at install time what to install, or does it always
> install all versions of things even when they mght not be needed (I'm
> thinking of installs on 32bit x86 boxes nowadays I suppose, but
> earlier on this must have been true for SPARC too)?
>
> Thanks
>
> --tim



In fact I never had any problems with 32/64bits but one exeption:

I had compiled and installed a device driver under Solaris 2.6
(32bits) and although it compiled Ok it refuse to load when the
machine (E4500) was upgraded to Solaris 8 (64bits).
I gave up as there were other solutions.
Zoot

On 24 May 2007 03:34:22 -0700 Tim Bradshaw <tfb+google@tfeb.org> wrote:
> should be true for packages, so I should never have to worry about
> whether there are 32 or 64 bit versions of things?  Does the package
> make a decision at install time what to install, or does it always
> install all versions of things even when they mght not be needed (I'm
> thinking of installs on 32bit x86 boxes nowadays I suppose, but
> earlier on this must have been true for SPARC too)?

I make this decision at build time.  If building on a 64-bit machine,
build both 32- and 64-bit versions of libraries.  For apps I just
build 32-bit versions.

-frank