Re: New procps, may break
firstname.lastname@example.org (Craig Small) writes:
> On Thu, Jul 29, 2004 at 02:46:40PM -0700, David S. Miller wrote:
>> Can you elaborate on the expected potential failure?
>> You do have something specific your worried about, otherwise
>> you wouldn't mention anything :-)
>> Thanks. And I'll try to help out with whatever explodes.
> Hello David,
> Probably the first thing I should mention is that the procps is
> different to the one RedHat uses (if you are here without the RedHat hat
> on then it doesn't matter). Just letting you know in case you're looking
> at their package and wondering what all the fuss is about.
> Yes, I suppose actually specifying what sort of breakage would of made
> everyone's job easier, sorry about that.
> The problems I would expect would be things like it doesn't compile
> correctly, it compiles but puts a 32 bit library in the wrong directory
> or puts a 64 bit library in the wrong directory.
> If you compile it, install it and are happy about what libproc.so.3.2.2
> is and where it has been installed then you have none of the foreseeable
> set of problems.
> I've hard-coded for the library to be installed in /lib to get around
> problems we had on one of the 64-bit arches, possibly sparc or hppa.
> I cannot find the bug # about it but it put the wrong file in the
> wrong directory.
> That hard coding might cause problems on sparc, but more likely on
> things like ia64, hppa or amd64. I don't understand those arches at
> - Craig
NEWS:install to /lib64 if it exists
Makefile:lib64 := lib$(shell [ -d /lib64 ] && echo 64)
The presence of /lib64 has nothing to do with it being used. Best way
to actualy test for it I can think of is compiling a conftest and
checking where it gets the libc from. That would work on all archs and
You're 'lib64=lib' in debian/rules should work for all debian
archs. It's what the README says to do after all. :)
-rw-r--r-- root/root 54304 2004-05-14 17:03:59 ./lib/libproc.so.3.2.1