Messages in this thread |  | | From | (James M. Cassidy) | Subject | Re: make | Date | Sun, 16 Jun 96 16:11:31 EDT |
| |
> In article <9606152139.AA13162@micro.ee.usm.maine.edu> you write: > > Well for your information I did read the release notes. I did recompile > >make and I STILL have the problem with the new excutable. > > Well, you'd probably have received more useful information if you'd > mentioned that in your original post. Are you sure you don't still have > old make versions on your path, and have you run ldconfig recently? > > Excuse me for suggesting such obvious possibilities, but I've never > heard of anyone still having this problem after having patched and > upgraded make (and I've had a whole bundle of mail on the subject, > let me tell you); 9 times out of ten the obvious problems are the > ones that come up.
Ya I've checked it, I even renamed the old 'make' to 'make.old' and did a search for any other possible old 'make' binaries. And then I even did ./make to use the new make to see if it could start to compiled itself again wiith the new binary and without the '-f' option. or their script. And I still got the same error.
I guess I'm just a prime example of murphy's law. :P
> > >Not too mention > >the little probablem their talking about should cause any problems with the > >old executables. When it comes to executing binaries your computer doesn't > >care what you use for variables name it removes them anyways in compilation > >unelss you tell it to include them for debugging. > > You're on dodgy ground here; you're arguing that something that DID HAPPEN > couldn't have done. Having to argue logic in the face of the evidence is > usually an indication that your logic is wrong ;-) > > d_namlen is the length of the `name' portion of the dirent structure. > d_reclen is the length of the whole structure (name + inode + offset > + padding to a `round number' length). Yes, d_reclen now occupies > the same offset in dirent that d_namlen used to, but no, they do not > store the same thing.
I wish they would have put that in the release notes. They just said the old lib just miss named the member. If I had known it held different information I would have known how that could effect it.
> > The change in behaviour is because libc now uses a new system call > (getdents) to fill out the dirent structures, and it stores the record > length at this offset instead of the name length. You can get the > name length by doing strlen(d_name) anyway, so you're not losing any > information. > > The old versions of libc use the old system call (which has a different > number and is still present) which fills that offset with the name length. > > Useful files to look at in this connection are /usr/include/linux/dirent.h, > and /usr/src/linux/fs/readdir.c. > > Hope this helps. If you still have problems with make, there is reputed > to be a patched and working binary on sunsite, which you might want to try.
I'll see if I can find that binary on sunsite perhaps somethings wrong with my compiling tools.
Thanks - Jim
> > Daniel > -- > http://ftp.linux.org.uk/~barlow/, dan@detached.demon.co.uk, PGP key ID 5F263625 > Unsolicited bulk email is unwelcome; senders can expect nasty things to happen > > ``He died? But this is supposed to be a kids' movie ...'' >
|  |