From @tomhukins

Hi,

On a FreeBSD system with SysV IPC enabled, it's possible to create
jails that lack this IPC support.

Currently, Perl 5 configures itself wrongly in this situation and
consequently fails its tests. I've attached a patch that fixes this
problem, perhaps not very elegantly as I'm unfamiliar with
"Configure". However, the patch makes it possible to build, test and
install perl in a FreeBSD jail without SysV IPC support.

Whilst fixing this bug, I noticed what looks like a very old typo so I
fixed that in a separate commit (also attached).

Tom

From @tomhukins

From ee0b514683296f5078d3be6616f7fe61c7c5a952 Mon Sep 17 00:00:00 2001
From: Tom Hukins <tom@eborcom.com>
Date: Fri, 14 Feb 2014 17:43:23 +0000
Subject: [PATCH 1/2] Build within a FreeBSD jail that lacks SysV IPC

---
 Configure        | 18 ++++++------------
 hints/freebsd.sh | 10 ++++++++++
 2 files changed, 16 insertions(+), 12 deletions(-)

diff --git a/Configure b/Configure
index 88ff021..f596081 100755
--- a/Configure
+++ b/Configure
@@ -15816,8 +15816,7 @@ case "$d_msgctl$d_msgget$d_msgsnd$d_msgrcv" in
 esac
 case "$osname" in
 freebsd)
-    case "`ipcs 2>&1`" in
-    "SVID messages"*"not configured"*)
+    if $without_sysvipc; then
 	echo "Your $osname does not have the msg*(2) configured." >&4
         h_msg=false
 	val="$undef"
@@ -15829,8 +15828,7 @@ freebsd)
 	eval $setvar
 	set msgrcv d_msgrcv
 	eval $setvar
-	;;
-    esac
+    fi
     ;;
 esac
 : we could also check for sys/ipc.h ...
@@ -17042,8 +17040,7 @@ case "$d_semctl$d_semget$d_semop" in
 esac
 case "$osname" in
 freebsd)
-    case "`ipcs 2>&1`" in
-    "SVID messages"*"not configured"*)
+    if $without_sysvipc; then
 	echo "Your $osname does not have the sem*(2) configured." >&4
         h_sem=false
 	val="$undef"
@@ -17053,8 +17050,7 @@ freebsd)
 	eval $setvar
 	set semop d_semop
 	eval $setvar
-	;;
-    esac
+    fi
     ;;
 esac
 : we could also check for sys/ipc.h ...
@@ -17722,8 +17718,7 @@ case "$d_shmctl$d_shmget$d_shmat$d_shmdt" in
 esac
 case "$osname" in
 freebsd)
-    case "`ipcs 2>&1`" in
-    "SVID shared memory"*"not configured"*)
+    if $without_sysvipc; then
 	echo "Your $osname does not have the shm*(2) configured." >&4
         h_shm=false
 	val="$undef"
@@ -17735,8 +17730,7 @@ freebsd)
 	evat $setvar
 	set shmdt d_shmdt
 	evat $setvar
-	;;
-    esac
+    fi
     ;;
 esac
 : we could also check for sys/ipc.h ...
diff --git a/hints/freebsd.sh b/hints/freebsd.sh
index a67c0bb..790bf7f 100644
--- a/hints/freebsd.sh
+++ b/hints/freebsd.sh
@@ -309,3 +309,13 @@ esac
 # Meanwhile, the following workaround should be safe on all versions
 # of FreeBSD.
 d_printf_format_null='undef'
+
+without_sysvipc=false
+case "`ipcs 2>&1`" in
+"SVID messages"*"not configured"*)
+    without_sysvipc=true
+    ;;
+esac
+if [ `sysctl -n security.jail.jailed``sysctl -n security.jail.sysvipc_allowed` = "10" ]; then
+    without_sysvipc=true
+fi
-- 
1.8.5.4


From 62be838e8936843ae439eb93b0682a50b861ae80 Mon Sep 17 00:00:00 2001
From: Tom Hukins <tom@eborcom.com>
Date: Thu, 27 Feb 2014 17:09:41 +0000
Subject: [PATCH 2/2] Replace what looks like a typo: s/evat/eval/

Revision 6087ac44 added the "evat" code, but nothing else in that
revision or blead contains "evat".  It looks like a typo for "eval".
---
 Configure | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/Configure b/Configure
index f596081..6cf502f 100755
--- a/Configure
+++ b/Configure
@@ -17723,13 +17723,13 @@ freebsd)
         h_shm=false
 	val="$undef"
 	set shmctl d_shmctl
-	evat $setvar
+	eval $setvar
 	set shmget d_shmget
-	evat $setvar
+	eval $setvar
 	set shmat d_shmat
-	evat $setvar
+	eval $setvar
 	set shmdt d_shmdt
-	evat $setvar
+	eval $setvar
     fi
     ;;
 esac
-- 
1.8.5.4

From @tonycoz

On Mon, Mar 03, 2014 at 02​:13​:16PM -0800, Tom Hukins wrote​:

On a FreeBSD system with SysV IPC enabled, it's possible to create
jails that lack this IPC support.

Currently, Perl 5 configures itself wrongly in this situation and
consequently fails its tests. I've attached a patch that fixes this
problem, perhaps not very elegantly as I'm unfamiliar with
"Configure". However, the patch makes it possible to build, test and
install perl in a FreeBSD jail without SysV IPC support.

Whilst fixing this bug, I noticed what looks like a very old typo so I
fixed that in a separate commit (also attached).

Have you tried building without these patches with bleadperl as of a
week ago?

I modified io/shm.t and op/taint.t to skip their tests if
shmget/msgget failed or SIGSYSed. This was required for cygwin, since
it only have SysV IPC if you set up cygserver.

The "evat"s look like a real problem.

Tony

The RT System itself - Status changed from 'new' to 'open'

From @tomhukins

On Tue, Mar 04, 2014 at 09​:51​:46AM +1100, Tony Cook wrote​:

Have you tried building without these patches with bleadperl as of a
week ago?

Yes, with blead as of 04775fa I see t/io/sem.t fail as follows​:

% ./perl t/io/sem.t
1..
semctl not implemented at t/io/sem.t line 50.

The "evat"s look like a real problem.

I also tried applying the "evat" fix to blead without my other patch
and saw the same test script fail.

Tom

From @tonycoz

On Tue Mar 04 00​:54​:01 2014, tomhukins wrote​:

On Tue, Mar 04, 2014 at 09​:51​:46AM +1100, Tony Cook wrote​:

Have you tried building without these patches with bleadperl as of a
week ago?

Yes, with blead as of 04775fa I see t/io/sem.t fail as follows​:

% ./perl t/io/sem.t
1..
semctl not implemented at t/io/sem.t line 50.

The "evat"s look like a real problem.

I also tried applying the "evat" fix to blead without my other patch
and saw the same test script fail.

Sorry for the long delay in responding.

I'm wondering how that test can produce that output.

io/sem.t includes the following code​:

  if ($Config{'d_sem'} ne 'define') {
  skip_all('-- $Config{d_sem} undefined');
  }

which means it should skip unless d_sem is defined, well before line 50.

If I'm reading perl.h and doio.c/Perl_do_ipcctl() correctly, that message can only be produced for semctl() when d_sem is not "define".

Could I please see the config.sh output from blead without your patches applied?

Thanks,
Tony

From @tomhukins

On Sun, May 11, 2014 at 09​:37​:48PM -0700, Tony Cook via RT wrote​:

Sorry for the long delay in responding.

That's fine. I appreciate your review.

I'm wondering how that test can produce that output.

io/sem.t includes the following code​:

if ($Config{'d_sem'} ne 'define') {
skip_all('-- $Config{d_sem} undefined');
}

which means it should skip unless d_sem is defined, well before line 50.

Without my patches, on a FreeBSD jail that has SysV IPC disabled,
running ipcs(1) does not fail. Consequently, config.sh mistakenly
contains​:

  d_sem='define'

My patch adds an additional check against the "security.jail.jailed"
and "security.jail.sysvipc_allowed" sysctls to set d_sem to "undef"
when necessary.

I hope I have explained the purpose of this patch more clearly.

Tom

From @Leont

On Mon, May 12, 2014 at 11​:11 AM, Tom Hukins <tom@​eborcom.com> wrote​:

Without my patches, on a FreeBSD jail that has SysV IPC disabled,
running ipcs(1) does not fail. Consequently, config.sh mistakenly
contains​:

d_sem='define'

My patch adds an additional check against the "security.jail.jailed"
and "security.jail.sysvipc_allowed" sysctls to set d_sem to "undef"
when necessary.

I hope I have explained the purpose of this patch more clearly.

I do not think this approach is the right one, and instead of improving it
I would argue for removing it entirely.

IMO, the test should be to see if the platforms supports the interface, not
if the particular configuration of the machine has enabled it; a perl build
inside a jail but run outside of it should still support SysV IPC, even if
it couldn't test it.

Leon

From @tomhukins

On Sun, May 11, 2014 at 09​:37​:48PM -0700, Tony Cook via RT wrote​:

Sorry for the long delay in responding.

I'm wondering how that test can produce that output.

I spent a little time discussing this with Tony on IRC yesterday. We
couldn't understand the problem so I said I'd look at it later.

However, it seems Gisle Aas has independently encountered this problem
and fixed it in v5.19.11-109-gdb93ece. As of this commit, I no longer
see test failures.

So, we don't need to apply my first patch. As Leon Timmermans
mentions, it's not the right solution anyway. Please don't close this
ticket until the s/evat/eval patch finds its way to blead, though.

Tom

From @tonycoz

On Wed May 14 04​:33​:58 2014, tomhukins wrote​:

On Sun, May 11, 2014 at 09​:37​:48PM -0700, Tony Cook via RT wrote​:

Sorry for the long delay in responding.

I'm wondering how that test can produce that output.

I spent a little time discussing this with Tony on IRC yesterday. We
couldn't understand the problem so I said I'd look at it later.

However, it seems Gisle Aas has independently encountered this problem
and fixed it in v5.19.11-109-gdb93ece. As of this commit, I no longer
see test failures.

So, we don't need to apply my first patch. As Leon Timmermans
mentions, it's not the right solution anyway. Please don't close this
ticket until the s/evat/eval patch finds its way to blead, though.

Thanks, Merijn applied this fix to metaconfig.git as d6c7ac14a4ebbbbd2c1bfdbe9ae7de6723a9d462 and the updated Configure to blead as b488de0.

Tony

@tonycoz - Status changed from 'open' to 'resolved'