[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: GLIBC 2.1 sparc, some good news



On Wed, Mar 24, 1999 at 03:36:00PM -0500, Steve Dunham wrote:
> "Collins M.  Ben " <bmc@visi.net> writes:
> 
> > After messing with this all night, finding out that perl and a ton of other packages need to be recompiled aswell as the ones we already
> > knew about, I did some hacking on the chown patch that has been used.
> > 
> > Our major problem was that the default symbol for the old chown was
> > GLIBC_2.1, when it shouldn't have been. chown vGLIBC_2.0 was also
> > defined, but not the default. What I am going to try is using the
> > old patch but making GLIBC_2.0 the default version as it should be,
> > and GLIBC_2.1 defined for compatibility with our old binaries. This
> > way nothing has to be recompiled, and anything compiled against this
> > new GLIBC 2.1 will work with our older 2.1pre aswell as other
> > systems such as RedHat, etc.
> 
> How did you do this?  (I didn't know you could change the default
> version on a case-by-case basis.)

Basically I am keeping the old patch as the GLIBC_2.1 version and just leaving
the symbol_version() defined, but not doing a weak_alias(). Then I am mapping
the GLIBC_2.0 version to __syscall_chown (since we are using 2.2.x kernels to
compile, this wont break anything). This way the GLIBC_2.0 version will work
same as the if we did not have a patch installed and the GLIBC_2.1 version will
simply be in the background for backward compatibility.

> FWIW, I've scanned my disk for problematic packages, they are
> 
<snip>long list</snip>
> 
> I did this using the following two perl scripts (which can be
> concatenated to make one script).  The first builds a
> filename->package index, and the second, scans all the bin directories
> for suspect binaries, builds a list for problematic packages, and then
> sorts and prints them.

That was my reason for doing this. We will have to rebuild all these eventually
(and with time they all will be rebuilt anyway). Atleast this way we don't have
to concern ourselves with dependencies and such or having to coordinate all the
uploads, aswell as troublesome upgrades.


Reply to: