lkml.org 
[lkml]   [1996]   [Jun]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: make
Date
> 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 ...''
>


\
 
 \ /
  Last update: 2005-03-22 13:37    [W:0.038 / U:3.604 seconds]
©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site