[EMAIL PROTECTED] (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 > all. > > - 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 distributions afaik. You're 'lib64=lib' in debian/rules should work for all debian archs. It's what the README says to do after all. :) On amd64: -rw-r--r-- root/root 54304 2004-05-14 17:03:59 ./lib/libproc.so.3.2.1 Looks fine. MfG Goswin