Trailing slashes on file names
Christian Weisgerber
not building on sparc64. The details seem to be twisty, but I
suspect at the root are these different results of a number of
configure script tests:
==== sparc64 ====
checking whether chown honors trailing slash... no
checking whether lstat dereferences a symlink specified with a trailing slash... no
checking whether unlink honors trailing slashes... no
checking whether open recognizes a trailing slash... no
checking whether stat handles trailing slashes on files... no
checking whether unlink honors trailing slashes... (cached) no
==== amd64, i386 ====
checking whether chown honors trailing slash... yes
checking whether lstat dereferences a symlink specified with a trailing slash... yes
checking whether unlink honors trailing slashes... yes
checking whether open recognizes a trailing slash... yes
checking whether stat handles trailing slashes on files... yes
checking whether unlink honors trailing slashes... (cached) yes
Whatever the expected behavior, it certainly shouldn't vary with
the architecture. Is this a problem of FreeBSD/sparc64? Something
in the build environment for the sparc64 section of the pointyhat
cluster?
--
Christian "naddy" Weisgerber na...@mips.inka.de
Peter Jeremy
>Whatever the expected behavior, it certainly shouldn't vary with
>the architecture. Is this a problem of FreeBSD/sparc64? Something
>in the build environment for the sparc64 section of the pointyhat
>cluster?
Do you have access to the config.log output? That may provide more
insight into what is going wrong. I have in the past seen configure
get very confused about how to compile test programs and blunder on
regardless, reporting nonsense.
--
Peter Jeremy
Christian Weisgerber
> Do you have access to the config.log output?
No, I have only been looking at the pointyhat logs, since I don't have
access to a FreeBSD/sparc64 machine. Is there one available to
committers? There is no mention on
http://www.freebsd.org/internal/machines.html
> That may provide more insight into what is going wrong. I have
> in the past seen configure get very confused about how to compile
> test programs and blunder on regardless, reporting nonsense.
The configure script doesn't get confused in general. If you diff
its output between amd64/i386 and sparc64, you see that it specifically
differs about whether a number of system calls accept a trailing
slash to a file name: chown, lstat, unlink, open, stat. Hundreds
of other tests are fine.
Anybody with access to a sparc64 can check what make configure for
ports/archivers/gcpio reports for their system.
I am concerned that linimon@ may have sprinkled BROKEN all over the
ports tree based on a bogus build run.
Craig Butler
On Tue, 2010-04-06 at 13:41 +0200, Christian Weisgerber wrote:
> Peter Jeremy:
>
> > Do you have access to the config.log output?
>
> No, I have only been looking at the pointyhat logs, since I don't have
> access to a FreeBSD/sparc64 machine. Is there one available to
> committers? There is no mention on
> http://www.freebsd.org/internal/machines.html
Hi Christian
I can setup access to a sparc64 box for you.... jail ok ?
>
> > That may provide more insight into what is going wrong. I have
> > in the past seen configure get very confused about how to compile
> > test programs and blunder on regardless, reporting nonsense.
>
> The configure script doesn't get confused in general. If you diff
> its output between amd64/i386 and sparc64, you see that it specifically
> differs about whether a number of system calls accept a trailing
> slash to a file name: chown, lstat, unlink, open, stat. Hundreds
> of other tests are fine.
>
> Anybody with access to a sparc64 can check what make configure for
> ports/archivers/gcpio reports for their system.
I will script a configure for you as soon as portsnap finishes.
>
> I am concerned that linimon@ may have sprinkled BROKEN all over the
> ports tree based on a bogus build run.
>
naughty boy :)
Cheers
Craig B
Craig Butler
> > Anybody with access to a sparc64 can check what make configure for
> > ports/archivers/gcpio reports for their system.
> I will script a configure for you as soon as portsnap finishes.
x1# make configure
===> gcpio-2.11 is marked as broken: Does not compile on sparc64:
invalid use of stat macro.
*** Error code 1
with the appropriate sparc64 check hashed out of Makefile -- see
attached
Craig Butler
On Fri, 2010-04-09 at 00:12 +0200, Christian Weisgerber wrote:
> Craig Butler:
>
> > checking whether chown honors trailing slash... no
> > checking whether lstat dereferences a symlink specified with a trailing slash... no
> > checking whether unlink honors trailing slashes... no
> > checking whether mkdir handles trailing slash... yes
> > checking whether mkdir handles trailing dot... yes
> > checking whether open recognizes a trailing slash... no
> > checking whether stat handles trailing slashes on directories... yes
> > checking whether stat handles trailing slashes on files... no
> > checking whether unlink honors trailing slashes... (cached) no
>
> Is there anything at all remarkable about the filesystem the work
> directory is on? NFS, nullfs, ...?
>
nope, normal ports sitting on a ufs partition.
%ls -ld /usr/ports
drwxr-xr-x 69 root wheel 1536 Apr 8 18:15 /usr/ports
%cd /usr/ports/archivers/gcpio
%ls -ld work
drwxr-xr-x 3 root wheel 512 Apr 8 19:14 work
%df -h work
Filesystem Size Used Avail Capacity Mounted on
/dev/ad0f 447G 97G 314G 24% /usr
%cat /etc/fstab | grep ad0f
/dev/ad0f /usr ufs rw 2
2
%mount | grep ad0f
/dev/ad0f on /usr (ufs, NFS exported, local, soft-updates)
NFS exported -- is because I export a couple of directories for
installing kernels across a couple of boxes... the whole directory isn't
exported and ports isn't in /etc/exports
Cheers
Craig Butler
Christian Weisgerber
> checking whether chown honors trailing slash... no
> checking whether lstat dereferences a symlink specified with a trailing slash... no
> checking whether unlink honors trailing slashes... no
> checking whether mkdir handles trailing slash... yes
> checking whether mkdir handles trailing dot... yes
> checking whether open recognizes a trailing slash... no
> checking whether stat handles trailing slashes on directories... yes
> checking whether stat handles trailing slashes on files... no
> checking whether unlink honors trailing slashes... (cached) no
Is there anything at all remarkable about the filesystem the work
directory is on? NFS, nullfs, ...?
--
Christian "naddy" Weisgerber na...@mips.inka.de
Christian Weisgerber
> > http://www.freebsd.org/internal/machines.html
>
> I can setup access to a sparc64 box for you....
Thank you, but hold off for the moment. I think sparc64 is a red
herring and whatever is going on does not depend on the machine
architecture.
I have now also seen the "sparc64" behavior on a 7.2/i386 box I
have a jailed user account on.
> jail ok ?
Actually, I wonder if it's a jail that changes the syscall behavior.
Peter Jeremy
>not building on sparc64. The details seem to be twisty, but I
>suspect at the root are these different results of a number of
>configure script tests:
I have checked with 8-stable sparc64, amd64 and i386 and am unable to
reproduce this particular problem and gcpio builds on sparc64 for me.
I _do_ get some other wierd issues though.
Environment:
sparc64: 8-stable from mid-Feb, UFS
amd64: 8-stable from last Sunday, ZFS
i386: 8-beta from last September, NFS [I didn't realise it was that old]
The "wierd" issues are:
sparc64, amd64:
checking for working fcntl.h... no (bad O_NOATIME)
checking whether stdint.h conforms to C99... no
checking whether inttypes.h conforms to C99... no
checking for working mktime... no
i386
checking for working fcntl.h... yes
checking whether stdint.h conforms to C99... yes
checking whether inttypes.h conforms to C99... yes
checking for working mktime... yes
O_NOATIME appears to be a Linux extension so the claim that fcntl.h
does not work on sparc64 or amd64 is spurious whilst the claim it
does work on i386 is a flaw in the configure script.
The definitions for SIG_ATOMIC_{MIN,MAX} in <stdint.h> are incorrect
on 64-bit architectures because they are always 32-bit whereas
sig_atomic_t is long (64-bit). I have reported this as bin/145590.
The inttypes.h non-conformance is linked to stdint.h non-conformance.
mktime is reported as non-working on 64-bit architectures because
localtime(3) and mktime(3) are not able to reverseably convert some
time_t values. There have been various discussions about range
restrictions within the timezone code. A short search has turned up
kern/128714 and misc/145341. IMO, the test program is unrealistic.
--
Peter Jeremy