Darrin B. Jewell | 1 May 20:31 2003
Picon

MacOS X tool build problem


I've been having trouble building the NetBSD src tools from a -current
source tree on MacOS X 10.2.5 using Apple's December 2002 dev tools.

It fails relatively quickly with make dependall in src/tools/binstall
the error is: 
   nbmake: don't know how to make /usr/lib/libc.a. Stop
Note that MacOS X does not ship with a static libc.

I noticed that LIBC is set to /usr/lib/libc.a in
src/share/mk/bsd.hostprog.mk and ${HOSTPROG} depends on ${LIBC}
I don't know how this relates to the problem I'm seeing.

Does anyone else see this problem or have any suggestions?

I've included a session log showing the problem below.

Thanks,
Darrin

Script started on Thu May  1 18:10:16 2003
sh-2.05a$ cd /Volumes/Data/work/trunkwork/src

sh-2.05a$ uname -a
Darwin Quiteria.local. 6.5 Darwin Kernel Version 6.5: Mon Apr  7 17:05:38 PDT 2003; root:xnu/xnu-344.32.obj~1/RELEASE_PPC  Power Macintosh powerpc

sh-2.05a$ cc -v
Reading specs from /usr/libexec/gcc/darwin/ppc/3.1/specs
Thread model: posix
Apple Computer, Inc. GCC version 1175, based on gcc version 3.1 20020420 (prerelease)
(Continue reading)

Jason Thorpe | 3 May 01:04 2003

Re: MacOS X tool build problem


On Thursday, May 1, 2003, at 11:31  AM, Darrin B. Jewell wrote:

> It fails relatively quickly with make dependall in src/tools/binstall
> the error is:
>    nbmake: don't know how to make /usr/lib/libc.a. Stop
> Note that MacOS X does not ship with a static libc.

Darrin... can you file a PR on this so there's a paper trail?

Anyway, I'm pretty sure that the hostprog Makefiles simply should not 
record dependencies on system libraries.

         -- Jason R. Thorpe <thorpej <at> wasabisystems.com>

Hubert Feyrer | 5 May 15:23 2003
Picon

Makefile.mbr problem - fix?


Regarding the recent problems in sys/arch/i386/stand/mbr/Makefile.mbr that
arise because our /bin/sh doesn't want to properly convert a hex value
into a decimal value (" echo $(( 0xdeadbeef )) "), below's a possible
solution that uses nm(1) to do the conversion to dec.

Problem is that it uses sed(1) to strip leading zeroes, and I'm not sure
that's ok. At least there is no $(SED) macro defined, is it ok to use
sed(1) in that way? (Thinking about cross builds...)

 - Hubert

Index: Makefile.mbr
===================================================================
RCS file: /cvsroot/src/sys/arch/i386/stand/mbr/Makefile.mbr,v
retrieving revision 1.2
diff -u -r1.2 Makefile.mbr
--- Makefile.mbr        2003/05/05 02:47:42     1.2
+++ Makefile.mbr        2003/05/05 13:16:01
 <at>  <at>  -26,8 +26,8  <at>  <at> 

 ${PROG}: ${OBJS}
        ${LD} -o ${PROG}.tmp ${LDFLAGS} -Ttext 0x600 ${OBJS}
-        <at>  set -- $$( ${NM} -t x ${PROG}.tmp | grep '\<mbr_space\>' ); \
-               echo "#### There are $$((0x$$1)) free bytes in ${PROG}"
+        <at>  set -- $$( ${NM} -t d ${PROG}.tmp | grep '\<mbr_space\>' | sed 's/^0*//' ); \
+               echo "#### There are $$1 free bytes in ${PROG}"
        ${OBJCOPY} -O binary ${PROG}.tmp ${PROG}
        rm -f ${PROG}.tmp

(Continue reading)

Simon Burge | 5 May 15:32 2003

Re: Makefile.mbr problem - fix?

Hubert Feyrer wrote:

> Problem is that it uses sed(1) to strip leading zeroes, and I'm not sure
> that's ok. At least there is no $(SED) macro defined, is it ok to use
> sed(1) in that way? (Thinking about cross builds...)

We only need to make a program a host tool and use $(PROG) if that
program has some NetBSD-specific change or purpose.  The toolchain is
obvious.  Tools like cat and pax have changes that our build process
depends on, whereas rm, grep, and sed we use on "standard" ways.  Note
we already use sed in /usr/share/mk/* now.

If there were a host OS with a sed that couldn't do 's/^0*//' then we'd
need to look at adding it as a host tool.

Simon.
--
Simon Burge                            <simonb <at> wasabisystems.com>
NetBSD Support and Service:         http://www.wasabisystems.com/

Hubert Feyrer | 5 May 15:37 2003
Picon

Re: Makefile.mbr problem - fix?

On Mon, 5 May 2003, Simon Burge wrote:
> If there were a host OS with a sed that couldn't do 's/^0*//' then we'd
> need to look at adding it as a host tool.

OK, thanks. I'll commit this then.
(after finding that we use "sed" 4321 times in our Makefiles :-)

 - Hubert

--

-- 
Want to get a clue on IPv6 but don't know where to start? Try this:
* Basics -> http://www.onlamp.com/pub/a/onlamp/2001/05/24/ipv6_tutorial.html
* Setup  -> http://www.onlamp.com/pub/a/onlamp/2001/06/01/ipv6_tutorial.html
Of course with your #1 IPv6 ready operating system -> http://www.NetBSD.org/

Ben Harris | 5 May 15:29 2003
Picon

Re: Makefile.mbr problem - fix?

In article <Pine.GSO.4.50.0305051523110.15999-100000 <at> rfhs8012.fh-regensburg.de> you write:
>Problem is that it uses sed(1) to strip leading zeroes, and I'm not sure
>that's ok. At least there is no $(SED) macro defined, is it ok to use
>sed(1) in that way? (Thinking about cross builds...)

As long as you don't use non-POSIX features of sed, it's OK.  We only have
variables where we might need to provide our own version of a utility if the
host one turns out to be deficient.

--

-- 
Ben Harris

Todd Vierling | 5 May 15:39 2003
Picon

Re: Makefile.mbr problem - fix?

On Mon, 5 May 2003, Simon Burge wrote:

: If there were a host OS with a sed that couldn't do 's/^0*//' then we'd
: need to look at adding it as a host tool.

Or just say `fsck off for that host', since that BRE is so simple and
standard that any such broken `sed' ain't worth the trouble.  8-)

--

-- 
-- Todd Vierling <tv <at> pobox.com>

Darrin B. Jewell | 5 May 16:15 2003
Picon

Re: Makefile.mbr problem - fix?


Hubert,

Thanks for noticing that this doesn't work in our shell and fixing
our tree quickly.  I had been cross compiling and therefore didn't
notice the problem.

However, I did consult the SUSv3 before making this change.  It would
appear that our shell is out of spec.

From the SUSv3 on arithmetic expansion in the shell:
  "Only the decimal-constant, octal-constant, and hexadecimal-constant
  constants specified in the ISO C standard, Section 6.4.4.1 are
  required to be recognized as constants."

I will file a PR about the shell bug.

Thanks,
Darrin

Hubert Feyrer <hubert.feyrer <at> informatik.fh-regensburg.de> writes:

> Regarding the recent problems in sys/arch/i386/stand/mbr/Makefile.mbr that
> arise because our /bin/sh doesn't want to properly convert a hex value
> into a decimal value (" echo $(( 0xdeadbeef )) "), below's a possible
> solution that uses nm(1) to do the conversion to dec.
> 
> Problem is that it uses sed(1) to strip leading zeroes, and I'm not sure
> that's ok. At least there is no $(SED) macro defined, is it ok to use
> sed(1) in that way? (Thinking about cross builds...)
(Continue reading)

Darrin B. Jewell | 5 May 19:17 2003
Picon

src/usr.bin/ktrace and cvs update


After a non-objdir build, if I try to do "cvs update -dP"
in src/usr.bin/ktrace, cvs will die because there is an
empty (i.e. Attic only) directory in the repository with
the same name as the target binary file in the local directory.

Its a minor annoyance, but it would be nice if it didn't
lose this way.

Darrin

$ ls -al
total 61
drwxrwxr-x    4 dbj  wheel   1024 May  5 17:03 .
drwxrwxr-x  229 dbj  wheel   4096 May  5 17:03 ..
-rw-rw-r--    1 dbj  wheel   7708 May  5 04:54 .depend
-rw-rw-r--    1 dbj  wheel     60 May  4 21:21 .gdbinit
drwxrwxr-x    2 dbj  wheel   1024 May  5 17:09 CVS
-rw-r--r--    1 dbj  wheel    294 Aug 27  2002 Makefile
drwxrwxr-x    3 dbj  wheel   1024 May  5 17:03 kdump
-rwxrwxr-x    1 dbj  wheel  11238 May  4 21:21 ktrace
-rw-r--r--    1 dbj  wheel   6983 May  5 17:03 ktrace.1
-rw-r--r--    1 dbj  wheel   8080 Dec  9 21:29 ktrace.c
-rw-rw-r--    1 dbj  wheel   4865 May  4 21:21 ktrace.cat1
-rw-r--r--    1 dbj  wheel   2298 Dec  9 21:29 ktrace.h
-rw-rw-r--    1 dbj  wheel   4680 May  4 21:21 ktrace.o
-rw-r--r--    1 dbj  wheel   2839 Dec  9 21:29 subr.c
-rw-rw-r--    1 dbj  wheel   1840 May  4 21:21 subr.o

$ cvs -q update -dP
(Continue reading)

David Laight | 5 May 23:15 2003
Picon

Re: Makefile.mbr problem - fix?

> However, I did consult the SUSv3 before making this change.  It would
> appear that our shell is out of spec.
> 
> >>From the SUSv3 on arithmetic expansion in the shell:
>   "Only the decimal-constant, octal-constant, and hexadecimal-constant
>   constants specified in the ISO C standard, Section 6.4.4.1 are
>   required to be recognized as constants."
> 
> I will file a PR about the shell bug.

The following patch will fix NetBSD's /bin/sh
(I assume it is proper lex - it seems to work!)

Index: arith_lex.l
===================================================================
RCS file: /cvsroot/src/bin/sh/arith_lex.l,v
retrieving revision 1.10
diff -u -p -r1.10 arith_lex.l
--- arith_lex.l	1999/02/05 07:52:52	1.10
+++ arith_lex.l	2003/05/05 21:07:35
 <at>  <at>  -61,7 +61,9  <at>  <at>  extern char *arith_buf, *arith_startbuf;

 %%
 [ \t\n]	{ ; }
-[0-9]+	{ yylval = atol(yytext); return(ARITH_NUM); }
+"0x"[0-9a-fA-F]+	{ yylval = strtoul(yytext, 0, 16); return(ARITH_NUM); }
+"0"[0-7]*	{ yylval = strtoul(yytext, 0, 8); return(ARITH_NUM); }
+[1-9][0-9]*	{ yylval = strtoul(yytext, 0, 10); return(ARITH_NUM); }
 "("	{ return(ARITH_LPAREN); }
 ")"	{ return(ARITH_RPAREN); }
(Continue reading)


Gmane