On Tue, Jul 22, 2008 at 11:27:13AM +0300, Boaz Harrosh wrote:
> I'm not sure I fully understand. Could you please explain what you
arch/um/include/init.h copies enough definitions from linux/compiler.h
and linux/init.h to implement initcall and exitcall et al. It can't
include the kernel headers because it's included in userspace files,
and libc and kernel headers don't mix.
What happened was that I copied enough to make a distinction between
gcc 3.3 and higher vs lower than 3.3 (for the latter, the kernel
defines __used as attribute(__unused) for some reason).
However, since my ifdefs weren't looking at the major version, these
definitions also held for gcc 4.x. And when I added unit-at-a-time,
the __unused started being taken seriously, and UML libc-side
initcalls were thrown out.
> Why is it that with same compiler, some systems had a problem and some
> did not? is it .config related?
I have no idea. When Ulrich Drepper first hit this, he and I had the
same base system, same architecture, same toolchain, same config, and
I didn't see it.
I've upgraded since then, so I can't test in the same environment, but
when I add the bug back in such that it hits with gcc 4.3, I get the
So, this is very mysterious.
> Also I would prefer if the:
> #define __used __attribute__((__used__))
> would get an #if ((__GNUC__* 100 + __GNUC_MINOR__) >= 303 )
> of its own because other wise this problem will return when
> gcc hits 5. Just as it returned now.
I don't see the point - this is all wrapped in __GNUC__ == 3 or 4. As
for gcc 5, linux/compiler has this to say:
# error Sorry, your compiler is too old/not recognized.
So the kernel totally won't build with gcc 5.
Work email - jdike at linux dot intel dot com