headers
Hisashi T Fujinaka | 6 Jul 2005 19:47

problems compiling i386-current (what's generating the second -l r?)

I got no bites in current-users and after rading the man page and
looking at the following line, I see that the nbinstall line below has
TWO -l commands. Anyone know why that is and why it gives me the error:

realpath: Not a directory

-- 
Hisashi T Fujinaka - htodd <at> twofifty.com
BSEE(6/86) + BSChem(3/95) + BAEnglish(8/95) + MSCS(8/03) + $2.50 = latte

---------- Forwarded message ----------
Date: Tue, 5 Jul 2005 20:44:54 -0700 (PDT)
From: Hisashi T Fujinaka <htodd <at> twofifty.com>
To: current-users <at> NetBSD.org
Subject: problems compiling i386-current and trying to figure out env variables

I'm just trying to do a "./build.sh -U distribution" and what I see is:

#   install  /usr/src/obj.i386/destdir.i386/lib/libc.so.12.129
STRIP=/usr/src/obj.i386/tooldir.NetBSD-3.99.7-i386/bin/i386--netbsdelf-strip 
/usr/src/obj.i386/tooldir.NetBSD-3.99.7-i386/bin/nbinstall -U -M
/usr/src/obj.i386/destdir.i386/METALOG -D /usr/src/obj.i386/destdir.i386 -h sha1 -N
/usr/src/etc -c  -r -o root -g wheel -m 444   libc.so.12.129 /usr/src/obj.i386/destdir.i386/lib/libc.so.12.129
STRIP=/usr/src/obj.i386/tooldir.NetBSD-3.99.7-i386/bin/i386--netbsdelf-strip
/usr/src/obj.i386/tooldir.NetBSD-3.99.7-i386/bin/nbinstall -U -M
/usr/src/obj.i386/destdir.i386/METALOG -D /usr/src/obj.i386/destdir.i386 -h sha1 -N
/usr/src/etc -l s -r   -l r /usr/src/obj.i386/destdir.i386/lib/libc.so.12.129 /usr/src/obj.i386/destdir.i386/usr/lib/libc.so.12.129
nbinstall: /usr/src/obj.i386/destdir.i386/lib/libc.so.12.129: realpath: Not a directory

*** Failed target:  /usr/src/obj.i386/destdir.i386/lib/libc.so.12.129
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jukka Salmi | 8 Jul 2005 17:07
Picon

hard links not metalogged correctly

Hello,

install(1) currently does not metalog hard links correctly; e.g. syss?tat
entries from my /etc/mtree/set.base look like

./usr/bin/systat  type=file mode=02555 uname=root gname=kmem sha1=...
./usr/bin/sysstat type=file mode=0555                        sha1=...

Obviously, only the first entry is correct:

$ ls -li /usr/bin/sys*tat
107653 -r-xr-sr-x  2 root  kmem  96480 Jul  7 15:43 /usr/bin/sysstat
107653 -r-xr-sr-x  2 root  kmem  96480 Jul  7 15:43 /usr/bin/systat

$ mtree -e -p / -f /etc/mtree/set.base
[...]
usr/bin/sysstat: 
	gid (0, 2)
	permissions (0555, 02555)

Two questions about makelink() from src/usr.bin/xinstall/xinstall.c:

- The mode being metalogged for hard links is the mode of the source link
  masked with 0777 - shouldn't this be 07777? I.e. why are e.g. the s[ug]id
  bits cleared? That's why the mode of entries like the sysstat entry above
  is logged wrong (even when running privleged).

- Why are owner, group and fflags ignored?

To fix the problem for privileged installs seems to be easy: just use the
(Continue reading)

Permalink | Reply | 4 comments |
headers
der Mouse | 8 Jul 2005 17:12
Picon

Re: hard links not metalogged correctly

> Two questions about makelink() from src/usr.bin/xinstall/xinstall.c:

> - The mode being metalogged for hard links is [...]
> - Why are owner, group and fflags ignored?

Perhaps because the mode, owner, group, etc, are all necessarily
inherited from the linked-to file, so there's no point in bothering
with them?

I think the right fix here is not to change the metalogged data for the
hardlink, but rather to make tools that listen to that data ignore the
values for a hardlink - or at the very least use the corresponding
values for the target (which must necessarily be earlier in the file,
right?) instead.

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       mouse <at> rodents.montreal.qc.ca
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B
Permalink | Reply | 1 comment |
headers
Alan Barrett | 8 Jul 2005 17:39
Gravatar

Re: hard links not metalogged correctly

On Fri, 08 Jul 2005, Jukka Salmi wrote:
> install(1) currently does not metalog hard links correctly; e.g. syss?tat
> entries from my /etc/mtree/set.base look like [...]

See PR toolchain/24457, where I reported exactly the same problem.

--apb (Alan Barrett)
Permalink | Reply | 1 comment |
headers
Jukka Salmi | 8 Jul 2005 18:17
Picon

Re: hard links not metalogged correctly

der Mouse --> tech-toolchain (2005-07-08 11:12:37 -0400):
> > Two questions about makelink() from src/usr.bin/xinstall/xinstall.c:
> 
> > - The mode being metalogged for hard links is [...]
> > - Why are owner, group and fflags ignored?
> 
> Perhaps because the mode, owner, group, etc, are all necessarily
> inherited from the linked-to file, so there's no point in bothering
> with them?

Sure, but using mtree syntax, you can specify how many links a file has
using the `nlink' keyword, but you can't specify which files these links
are. No, specifying identical checksums doesn't count ;-)

> I think the right fix here is not to change the metalogged data for the
> hardlink, but rather to make tools that listen to that data ignore the
> values for a hardlink - or at the very least use the corresponding
> values for the target (which must necessarily be earlier in the file,
> right?) instead.

This doesn't work because for hard links both source and target file(s)
are specified as `type=file', so you can't distinguish them.

To make this work, a new keyword needs to be added to mtree which could
be used to describe the files which are hard links to the current file.
Or one abuses the `tags' keyword for this, and delegates parsing to the
reader...

Regards, Jukka
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jukka Salmi | 8 Jul 2005 18:38
Picon

Re: hard links not metalogged correctly

Alan Barrett --> tech-toolchain (2005-07-08 17:39:38 +0200):
> On Fri, 08 Jul 2005, Jukka Salmi wrote:
> > install(1) currently does not metalog hard links correctly; e.g. syss?tat
> > entries from my /etc/mtree/set.base look like [...]
> 
> See PR toolchain/24457, where I reported exactly the same problem.

Erm, thanks! I should have searched the PR database...

Cheers, Jukka

--

-- 
bashian roulette:
$ ((RANDOM%6)) || rm -rf ~
Permalink | Reply | 0 comments |
headers
Bernd Sieker | 14 Jul 2005 10:13
Picon
Picon

can't link GENERIC_SUN4U in sparc release crossbuild

Hi,

cross-building a -current release snapshot for sparc fails while
trying to link the 32bit-Kernel for sun4u machines.

Host is 2.0_STABLE/i386, target is sparc, sources are -current,
last updated Jul 13 12:35.

Linking of the GENERIC_SUN4U kernel fails with the following
messages:

[...]
#      link  GENERIC_SUN4U/netbsd
/usr/source/current/src/obj/tooldir.NetBSD-2.0_STABLE-i386/bin/sparc--netbsdelf-ld -n -T
/usr/source/current/src/sys/arch/sparc64/conf/kern32.ldscript -Ttext 01000000 -Tdata 01800000
-e start -S -o netbsd ${SYSTEM_OBJ} ${EXTRA_OBJ} vers.o
/usr/source/current/src/obj/tooldir.NetBSD-2.0_STABLE-i386/bin/sparc--netbsdelf-ld: section
.data [01800000 -> 0183e2d7] overlaps section .rodata [0175afe8 -> 0189db3f]
/usr/source/current/src/obj/tooldir.NetBSD-2.0_STABLE-i386/bin/sparc--netbsdelf-ld: section
.bss [0183e2d8 -> 0187803f] overlaps section .rodata [0175afe8 -> 0189db3f]

*** Failed target:  netbsd
[...]

I had previously removed all object directories and also explicitly rebuilt the toolchain
with "./build.sh -r -m sparc tools"

Regards,
Bernd
(Continue reading)

Permalink | Reply | 6 comments |
headers
Martin Husemann | 14 Jul 2005 10:41
Picon

Re: can't link GENERIC_SUN4U in sparc release crossbuild

On Thu, Jul 14, 2005 at 10:13:29AM +0200, Bernd Sieker wrote:
> Linking of the GENERIC_SUN4U kernel fails with the following
> messages:
> 
> [...]
> #      link  GENERIC_SUN4U/netbsd
> /usr/source/current/src/obj/tooldir.NetBSD-2.0_STABLE-i386/bin/sparc--netbsdelf-ld -n -T
/usr/source/current/src/sys/arch/sparc64/conf/kern32.ldscript -Ttext 01000000 -Tdata 01800000
-e start -S -o netbsd ${SYSTEM_OBJ} ${EXTRA_OBJ} vers.o
> /usr/source/current/src/obj/tooldir.NetBSD-2.0_STABLE-i386/bin/sparc--netbsdelf-ld:
section .data [01800000 -> 0183e2d7] overlaps section .rodata [0175afe8 -> 0189db3f]
> /usr/source/current/src/obj/tooldir.NetBSD-2.0_STABLE-i386/bin/sparc--netbsdelf-ld:
section .bss [0183e2d8 -> 0187803f] overlaps section .rodata [0175afe8 -> 0189db3f]

This has been reported before, but I can't reproduce it (though I don't have a
2.0.x machine - which realy should not matter).

Martin
Permalink | Reply | 0 comments |
headers
Soren Jacobsen | 16 Jul 2005 08:40
Picon

Re: can't link GENERIC_SUN4U in sparc release crossbuild

On Jul 14, 2005, at 1:13 AM, Bernd Sieker wrote:

> Hi,
>
> cross-building a -current release snapshot for sparc fails while
> trying to link the 32bit-Kernel for sun4u machines.
>
> Host is 2.0_STABLE/i386, target is sparc, sources are -current,
> last updated Jul 13 12:35.
>
> Linking of the GENERIC_SUN4U kernel fails with the following
> messages:
>
> [...]
> #      link  GENERIC_SUN4U/netbsd
> /usr/source/current/src/obj/tooldir.NetBSD-2.0_STABLE-i386/bin/ 
> sparc--netbsdelf-ld -n -T /usr/source/current/src/sys/arch/sparc64/ 
> conf/kern32.ldscript -Ttext 01000000 -Tdata 01800000 -e start -S -o  
> netbsd ${SYSTEM_OBJ} ${EXTRA_OBJ} vers.o
> /usr/source/current/src/obj/tooldir.NetBSD-2.0_STABLE-i386/bin/ 
> sparc--netbsdelf-ld: section .data [01800000 -> 0183e2d7] overlaps  
> section .rodata [0175afe8 -> 0189db3f]
> /usr/source/current/src/obj/tooldir.NetBSD-2.0_STABLE-i386/bin/ 
> sparc--netbsdelf-ld: section .bss [0183e2d8 -> 0187803f] overlaps  
> section .rodata [0175afe8 -> 0189db3f]

Are you using -pipe?  If so, don't :)
Permalink | Reply | 4 comments |
headers
Bernd Sieker | 16 Jul 2005 10:15
Picon
Picon

Re: can't link GENERIC_SUN4U in sparc release crossbuild

On 15.07.05, 23:40:53, Soren Jacobsen wrote:
> On Jul 14, 2005, at 1:13 AM, Bernd Sieker wrote:

> >[...]
> >#      link  GENERIC_SUN4U/netbsd
> >/usr/source/current/src/obj/tooldir.NetBSD-2.0_STABLE-i386/bin/ 
> >sparc--netbsdelf-ld -n -T /usr/source/current/src/sys/arch/sparc64/ 
> >conf/kern32.ldscript -Ttext 01000000 -Tdata 01800000 -e start -S -o  
> >netbsd ${SYSTEM_OBJ} ${EXTRA_OBJ} vers.o
> >/usr/source/current/src/obj/tooldir.NetBSD-2.0_STABLE-i386/bin/ 
> >sparc--netbsdelf-ld: section .data [01800000 -> 0183e2d7] overlaps  
> >section .rodata [0175afe8 -> 0189db3f]
> >/usr/source/current/src/obj/tooldir.NetBSD-2.0_STABLE-i386/bin/ 
> >sparc--netbsdelf-ld: section .bss [0183e2d8 -> 0187803f] overlaps  
> >section .rodata [0175afe8 -> 0189db3f]
> 
> Are you using -pipe?  If so, don't :)

Why would that matter?

And also, until just a few weeks ago I could build sparc releases
on i386, and it suddenly stopped working with the above message.

I might try building one natively, but that takes a long time.

I also noticed that the releng binary snapshots have had failures
for sparc builds for the last couple of days. Also with the SUN4U
kernel, but in a slightly different place. See
  http://releng.netbsd.org/builds/HEAD/200507140000Z/sparc.build.failed
(Continue reading)

Permalink | Reply | 3 comments |

Gmane