In message: <20080304153730.GA61036@kobe.laptop>
Giorgos Keramidas writes:
: On 2008-03-04 15:15, Robert Watson wrote:
: > On Mon, 3 Mar 2008, M. Warner Losh wrote:
: >> --- pmake.orig/config.h 2005-02-01 03:50:35.000000000 -0700
: >> +++ pmake/config.h 2008-03-03 22:24:16.745493000 -0700
: >> @@ -108,4 +108,27 @@
: >> # endif
: >> #endif
: >>
: >> +#ifndef TAILQ_HEAD_INITIALIZER
: >> +#define TAILQ_HEAD_INITIALIZER(head) { NULL, &(head).tqh_first }
: >> +#endif
: >
: > In most ports of FreeBSD parts to Linux that I've seen, the preferred
: > solution has to been to bring the entire FreeBSD queue.h with you rather
: > than relying on the native Linux queue.h. This is what we do for OpenBSM,
: > for example; this also helps out when you get to Mac OS X, Solaris, etc,
: > where all the queue.h's continue to vary in subtle ways. This depends a
: > fair amount on a lack of header pollution in the OS's own include files, of
: > course...
:
: Fortunately, in Solaris where I am testing the import of sys/cdefs.h and
: sys/queue.h today, things seem to be `ok'. Just importing the two
: headers at http://hg.hellug.gr/bmake/gker/rev/68bfc25ed443 seems to have
: moved things one step closer towards building everything on Solaris:
:
: Now off to the next little annoyance. Building with Sun Studio on
: Solaris 10, in my test machine at home, stops at:
:
: "arch.c", line 1063: undefined symbol: INT_MIN
: cc: acomp failed for arch.c
: *** Error code 2
: make: Fatal error: Command failed for target `arch.o'
: Current working directory /home/keramida/bmake/src
:
: This is easy to fix with:
:
: diff -r 68bfc25ed443 src/arch.c
: --- a/src/arch.c Tue Mar 04 17:29:11 2008 +0200
: +++ b/src/arch.c Tue Mar 04 17:35:08 2008 +0200
: @@ -96,6 +96,7 @@
: #include
: #include
: #include
: +#include
: #include
: #include
: #include

We likely should just commit this to FreeBSD's make, since Section
5.2.4.2.1 of the C standard says that INT_MIN is defined there.

: The next part, about the missing errx() functions on Solaris is going to
: be tonight's fun. If there are too many missing functions, it may be
: worth adding a static `libcompat' with copies of just the functions we
: need to run BSD make on non-BSD hosts.

In the longer term, this likely is a good idea. In the shorter term,
I'm not so sure that this is a good idea, since all you'd need would
be inlines for the functions that make uses.

Warner
_______________________________________________
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/lis...reebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org"