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 ...''
>