Its hard to believe its only my toolchain

After compiling some older versions I found out the problem start with 1.8.2
It does not happen with 1.8.1

So after some diffs I'm sure its the trylink script
If I make a diff between 1.8.1 and 1.8.2 and I reverse this on 1.9.0 my
problem is gone

I did include the diff
its somewhere in the SORT_SECTION (check_cc)
if someone can tell me how to provide more info please let me know because I
still think its not only toolchain related

(Sorry I can't program C)


> -----Oorspronkelijk bericht-----
> Van: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] Denys Vlasenko
> Verzonden: maandag 11 februari 2008 9:07
> Aan: [email protected]
> Onderwerp: Re: Busybox make, modify my /dev/null on host
>
>
> On Sunday 10 February 2008 22:26, Mike Frysinger wrote:
> > On Sunday 10 February 2008, Martinb_ARM_NOMMU_KISSDVD wrote:
> > > After 2 weeks of the strangest things happening to my
> /dev/null I did find
> > > a relation on this problem and the use of busybox (compiling)
>
> This is a generic UNIX administration problem.
> Many programs would inadvertently delete /dev/null
> in unusual cases. Heck, even busybox had a bug where
> if you would specify that pidfile is "/dev/null",
> it was deleting it! Now we protect against that:
>
> void write_pidfile(const char *path)
> {
> ...
>         pid_fd = open(path, O_WRONLY|O_CREAT|O_TRUNC, 0666);
>         if (pid_fd < 0)
>                 return;
>
>         /* path can be "/dev/null"! Test for such cases */
>         wrote_pidfile = (fstat(pid_fd, &sb) == 0) && S_ISREG(sb.st_mode);
> ...
> }
>
> #define remove_pidfile(path) do { if (wrote_pidfile)
> unlink(path); } while (0)
>
>
> >From the POV of UNIX admin, though, I find it impractical to ensure
> that all installed programs are not buggy. I want to make /dev/null
> not deletable instead. ext[23] immutable bit can help, but what to do
> on ramfs? :(
>
> > your toolchain is broken.  either dont build as root or upgrade
> your gcc and
> > binutils.  older versions of both would unlink the output even
> if it were a
> > character device.
>
> Yes, it probably happens somewhere here:
>
>
> scripts/trylink:
>
> check_cc() {
>     if $CC $1 -shared -o /dev/null -xc /dev/null >/dev/null 2>&1; then
>         echo "$1";
>     else
>         echo "$2";
>     fi
> }
>
>
> scripts/Kbuild.include:
>
> as-option = $(shell if $(CC) $(CFLAGS) $(1) -Wa,-Z -c -o /dev/null \
>              -xassembler /dev/null > /dev/null 2>&1; then echo "$(1)"; \
>              else echo "$(2)"; fi ;)
>
>
> (these are just examples, there are more such cases).
>
> Add ls -l /dev/null before and after these statements and you
> will see which invocation of gcc kills /dev/null.
> --
> vda
> _______________________________________________
> busybox mailing list
> [email protected]
> http://busybox.net/cgi-bin/mailman/listinfo/busybox

Attachment: trylinkbug.diff
Description: Binary data

_______________________________________________
busybox mailing list
[email protected]
http://busybox.net/cgi-bin/mailman/listinfo/busybox

Reply via email to