[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Problem compiling SMU driver [was: Cross compiling linux-2.6.12-rc1 G4 -> G5]



Hi all,

On Sun, 2005-04-10 at 06:57, Charles Lepple wrote:
> On Apr 10, 2005 5:07 PM, Michael <michael_six@users.sourceforge.net> wrote:
> > Just sticking in my two cents on this one.  When you say Xcode and
> > Darwin on your G5 I am assuming you mean Pather (OS 10.3) and in my
> > experience I have also found that The Mac OS X's (more so in Jaguar than
> > Panther), are incomplete as far as Darwin.  Some files needed to compile
> > certain things just aren't there.  For instance Jaguar does not contain
> > a poll.h for one, so that error on not being able to find sys.h might
> > not be your not having installed XCode right.
> 
> I would guess that this holds true in general, but it really shouldn't
> be applicable to cross-compiling a Linux kernel under OS X (or
> Darwin).

I was not really cross compiling between two different architectures
there, as I was compiling on a G5 (Darwin) for my G5 (Linux).

> Because the kernel does not rely on an external C library, it really
> shouldn't be looking in /usr/include for its header files. A properly
> built cross-compiler will look in its own private header directories
> for any .h files needed, but most of the ones required by the kernel
> are in its own include/ and include/asm directories.

My description was incomplete: the compilation of a linux kernel starts
by compiling some helper programs. These programs are not really part of
the kernel, but are used later on during the compilation process (to
resolve dependencies and the like).The first "sys/types.h not being
found" error I got was due to XCode not being completely installed (I
think I had skipped the Darwin SDK for some stupid reason). However,
even with the SDK properly set up, the compilation process stalls on the
helper programs because of include files not being at the expected
location.

> >  Also I have come across a
> > few programs were to get them to compile I had to "hard wire" the
> > #include that made the call to the *.h file.  By that I mean find the
> > file, and change the #include to "#include <full_path_to_file.h>"
> 
> all I can say is that if you find yourself having to do this, you
> would be wise to mention these changes to the authors when you report
> build problems with a package. Usually, if a compiler can't find an
> include file, something went wrong during configuration.

The gcc I was using is Apple's own. I could report it to them, but I'm
not sure they'd bother very much. :-}

Cheers!

Francois

> -- 
> - Charles Lepple



Reply to: