4.1.30 and 4.1.31 build failure on S10x86 5/08
J.D. Bronson
4.1.30, 4.1.31, 5.0.4 all fail on arc4random.c
[4.1.29 compiles just fine....]
I didnt see anything in the list archives about anyone reporting
a problem....
/opt/SUNWspro/prod/bin/cc -Xa -xildoff -I. -I../.. -DIPFILTER_LKM
-I../../../pfil -D_KERNEL -DSUNDDI -DSOLARIS2=10 -DIPFILTER_LOG
-DIPFILTER_LOOKUP -DIPFILTER_SCAN -c ../../radix.c -o radix.o
/opt/SUNWspro/prod/bin/cc -Xa -xildoff -I. -I../.. -DIPFILTER_LKM
-I../../../pfil -D_KERNEL -DSUNDDI -DSOLARIS2=10 -DIPFILTER_LOG
-DIPFILTER_LOOKUP -DIPFILTER_SCAN -c ../../md5.c -o md5.o
/opt/SUNWspro/prod/bin/cc -Xa -xildoff -I. -I../.. -DIPFILTER_LKM
-I../../../pfil -D_KERNEL -DSUNDDI -DSOLARIS2=10 -DIPFILTER_LOG
-DIPFILTER_LOOKUP -DIPFILTER_SCAN -DNEED_LOCAL_RAND=1 -c
../../arc4random.c -o arc4random.o
"../../arc4random.c", line 46: warning: no explicit type given
"../../arc4random.c", line 46: syntax error before or at: void
"../../arc4random.c", line 242: warning: pointer to void or function
used in arithmetic
"../../arc4random.c", line 242: warning: pointer to void or function
used in arithmetic
cc: acomp failed for ../../arc4random.c
*** Error code 2
make: Fatal error: Command failed for target `arc4random.o'
Current working directory /export/home/junk/ip_fil4.1.31/SunOS5/i386-5.10
*** Error code 1
make: Fatal error: Command failed for target `sunos5'
Current working directory /export/home/junk/ip_fil4.1.31
*** Error code 1
make: Fatal error: Command failed for target `solaris'
..this is with all patches and after a full fresh install.
Charles Seeger
|
| (Using Sun Studio 12 with all patches and OS fully patched)
|
| 4.1.30, 4.1.31, 5.0.4 all fail on arc4random.c
|
| [4.1.29 compiles just fine....]
Similar problems on Solaris 8 SPARC. See:
http://sourceforge.net/tracker/index.php?func=detail&aid=2063742&group_id=169098&atid=849053
As said there, the patch gets the compile to complete, but I haven't
tested the result (I have 4.1.29 installed, and it is likely to be
a while before I get back to this). The same patch submitted there
is included below. Let us know if it actually works. 8-)
HTH,
Chuck
--
Charles Seeger
see...@cise.ufl.edu
--- arc4random.c.orig 2008-07-26 16:08:18.000000000 -0400
+++ arc4random.c 2008-09-07 22:10:35.738378000 -0400
@@ -18,6 +18,9 @@
#ifdef __FreeBSD__
# include <sys/libkern.h>
#endif
+#ifdef SUNDDI
+# include <sys/conf.h> /* uniqtime() decl from <sys/systm.h> */
+#endif
#include <sys/lock.h>
#include <sys/mutex.h>
#include <sys/time.h>
@@ -25,6 +28,9 @@
#include <sys/socket.h>
#include <net/if.h>
#include <netinet/in.h>
+#ifdef SOLARIS2
+# include <netinet/in_systm.h> /* n_long typedef */
+#endif
#include <netinet/ip.h>
#include "netinet/ip_compat.h"
#include "md5.h"
@@ -43,7 +49,11 @@
static u_int8_t arc4_randbyte(void);
static int ipf_read_random(void *dest, int length);
+#ifdef __SUNPRO_C
+static inline void
+#else
static __inline void
+#endif
arc4_swap(u_int8_t *a, u_int8_t *b)
{
u_int8_t c;
J.D. Bronson
>| 4.1.30, 4.1.31, 5.0.4 all fail on arc4random.c
>|
>| [4.1.29 compiles just fine....]
>
>Similar problems on Solaris 8 SPARC. See:
>
>
>http://sourceforge.net/tracker/index.php?func=detail&aid=2063742&group_id=169098&atid=849053
>
>As said there, the patch gets the compile to complete, but I haven't
>tested the result (I have 4.1.29 installed, and it is likely to be
>a while before I get back to this). The same patch submitted there
>is included below. Let us know if it actually works. 8-)
as expected, the patch permits the compile to complete.
I am leery of testing this in the real world though.
Why? - This was posted to sourceforge OVER A MONTH AGO and there has been
no feedback or comments from Darren or anyone else.
Is IPFilter still supported and maintained?
If so, why has there been no 'official' word about this compile issue and
if this provided patch you submitted is appropriate ???
Unless I am missing something here?
-JD
Charles Seeger
|
| At 09:07 PM 10/17/2008 -0400, you wrote:
| >| 4.1.30, 4.1.31, 5.0.4 all fail on arc4random.c
| >|
| >| [4.1.29 compiles just fine....]
| >
| >Similar problems on Solaris 8 SPARC. See:
| >
| >
| >http://sourceforge.net/tracker/index.php?func=detail&aid=2063742&group_id=169098&atid=849053
| >
| >As said there, the patch gets the compile to complete, but I haven't
| >tested the result (I have 4.1.29 installed, and it is likely to be
| >a while before I get back to this). The same patch submitted there
| >is included below. Let us know if it actually works. 8-)
|
|
| as expected, the patch permits the compile to complete.
Good to hear that it compiles on Solaris 10 as well as 8.
| I am leery of testing this in the real world though.
|
| Why? - This was posted to sourceforge OVER A MONTH AGO and there has been
| no feedback or comments from Darren or anyone else.
Do consider that likely I was delinquent in only putting it up on
the Sourceforge bug tracker without announcing it either here or
to Darren privately. Also consider that Solaris 10 comes with
IPFilter already compiled, so relatively few will be attempting
to compile the latest versions on that platform. The new features
in 4.1.31 over 4.1.29, of which the arc4random.c is a major part,
are not of much immediate use in my environment.
OTOH, it seems as though Darren has or had some employment or
crontracting connection with Sun, presummably with integrating
IPFilter into Solaris (and perhaps more). So, I'm a bit suprised
that he allowed something to creep into IPFilter with compilation
problems on Solaris. Although arc4random.c appears to have been
a contribution from the FreeBSD community, and it may have been
rushed into IPFilter, I too am a bit disappointed not to see a
fix since the release back in late July. I'm guessing that
Darren has been busy with other tasks. Improving the IPFilter
build system hopefully is on his task list somewhere. 8-)
Best Regards,
Chuck
And thanks to Darren for all his contributions, past and future.
Darren Reed
Hash: SHA1
J.D. Bronson wrote:
| At 09:07 PM 10/17/2008 -0400, you wrote:
|> | 4.1.30, 4.1.31, 5.0.4 all fail on arc4random.c
|> |
|> | [4.1.29 compiles just fine....]
|>
|> Similar problems on Solaris 8 SPARC. See:
|>
|>
|>
http://sourceforge.net/tracker/index.php?func=detail&aid=2063742&group_id=169098&atid=849053
|>
|> As said there, the patch gets the compile to complete, but I haven't
|> tested the result (I have 4.1.29 installed, and it is likely to be
|> a while before I get back to this). The same patch submitted there
|> is included below. Let us know if it actually works. 8-)
|
|
| as expected, the patch permits the compile to complete.
|
| Why? - This was posted to sourceforge OVER A MONTH AGO and there has been
| no feedback or comments from Darren or anyone else.
|
So, this problem is with Solaris 8.
My priority is with Solaris 9 & 10 because I can easily run them the
x86 versions in a virtual machine rather than needing to power a whole
other system.
Darren
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkj6c6UACgkQP7JIXtvLbFUoEgCdEnuFMYsjffnh2hf2tvSoO2Jz
CgEAoK2Mg8acDdZQcvNxMWcm118h9n0S
=rDUQ
-----END PGP SIGNATURE-----
Darren Reed
J.D. Bronson
>So, this problem is with Solaris 8.
>
>My priority is with Solaris 9 & 10 because I can easily run them the
>x86 versions in a virtual machine rather than needing to power a whole
>other system.
>
>Darren
Thank you for replying Darren...however, this is indeed
a Solaris 10 issue...
I am running Solaris 10 05/08......
% cat /etc/release
Solaris 10 5/08 s10x_u5wos_10 X86
Copyright 2008 Sun Microsystems, Inc. All Rights Reserved.
Use is subject to license terms.
Assembled 24 March 2008
-JD
Darren Reed
Hash: SHA1
J.D. Bronson wrote:
|> So, this problem is with Solaris 8.
|>
|> My priority is with Solaris 9 & 10 because I can easily run them the
|> x86 versions in a virtual machine rather than needing to power a whole
|> other system.
|>
|> Darren
|
| Thank you for replying Darren...however, this is indeed
| a Solaris 10 issue...
Right... it appears that your problem is Sun's C compiler.
If you do "setenv CC gcc" (or "export CC=gcc), does the build succeed?
Darren
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkj6jeMACgkQP7JIXtvLbFUNYgCg7DyvwK4yh+ZnLLcg5Ym/b/6s
A9IAoJYNHHyv8QHNpF2j/LlbP/SEDfy9
=IkFH
-----END PGP SIGNATURE-----
J.D. Bronson
>Right... it appears that your problem is Sun's C compiler.
>
>If you do "setenv CC gcc" (or "export CC=gcc), does the build succeed?
>
>Darren
I do not run gcc nor do I have it on these machines for testing.
(It was not installed)
All programs are compiled with Studio 12.
So I cant answer that. However, if we could have you review the patch
that Charles submitted and give some feedback, that would be great.
His patch does allow a clean compile under Studio 12.
Thanks again Darren.
In the meantime, I have compiled 4.1.29 and it compiles/runs fine.
-JD
Charles Seeger
|
| Right... it appears that your problem is Sun's C compiler.
|
| If you do "setenv CC gcc" (or "export CC=gcc), does the build succeed?
Darren, if you examine the patch, only one of the three changes is
compiler related. The other two involve including headers to get
all the definitions required by the code. The entire arc4random.c
udiff is only 34 lines, containing 10 new lines.
Best,
Chuck
Darren Reed
Hash: SHA1
I'll have to install solaris 8 to check this out...
S10 doesn't require the other includes, only the workaround for __inline.
Cheers,
Darren
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkj6ticACgkQP7JIXtvLbFXr7QCZATVdYiUB/DB3qgiSFpvBtWrr
cwcAoLKXmbFBpkw1JVnp22ISld+Vgi//
=zzgi
-----END PGP SIGNATURE-----
J.D. Bronson
>I'll have to install solaris 8 to check this out...
>
>S10 doesn't require the other includes, only the workaround for __inline.
>
>Cheers,
>Darren
Could someone possibly provide a S10 'only' patch from this so I can test?
I will try and install GCC today and see if I can get IPFilter to compile
as well - for a 2nd thought.
-JD
J.D. Bronson
GCC 3.4.6 permits a complete build of 4.1.31 on Solaris 10.
In fact, there are much less error comments than with Studio12.
-JD
Charles Seeger
+------ "J.D. Bronson" wrote (Sun, 20-Dec-71, 20:02 -0500):
|
| At 09:23 PM 10/18/2008 -0700, Darren Reed wrote:
| >I'll have to install solaris 8 to check this out...
| >
| >S10 doesn't require the other includes, only the workaround for __inline.
| >
| >Cheers,
| >Darren
|
| Could someone possibly provide a S10 'only' patch from this so I can test?
That would be just this part of the original diff:
@@ -43,7 +49,11 @@
static u_int8_t arc4_randbyte(void);
static int ipf_read_random(void *dest, int length);
+#ifdef __SUNPRO_C
+static inline void
+#else
static __inline void
+#endif
arc4_swap(u_int8_t *a, u_int8_t *b)
{
u_int8_t c;
Though those line numbers would change to "@@ -43,7 +43,11 @@"
without the previous six extra lines for the includes.
If one wants to guard the gcc "__inline" (or any other gcc-isms),
the "__GNUC__" cpp macro might be best choice, short of using any
autoconf-like generated macros. Something like:
#if defined __GNUC__
static __inline void
#elif defined __SUNPRO_C
static inline void
#else
static void
#endif
Alas, I haven't used any other compilers recently enough to recall
what might be appropriate for them. A quick look at GNU autoconf
suggests that some compilers use "__inline__". Since autoconf
actually tests for all three, it doesn't enumerate which compiler
uses which inline flavor.
Best,
Chuck
Darren Reed
Hash: SHA1
| At 06:36 PM 10/18/2008 -0700, Darren Reed wrote:
|> Right... it appears that your problem is Sun's C compiler.
|>
|> If you do "setenv CC gcc" (or "export CC=gcc), does the build succeed?
|>
|
| I do not run gcc nor do I have it on these machines for testing.
| (It was not installed)
| All programs are compiled with Studio 12.
Technically, you're not supposed to be using Studio 12 on Solaris 8
as the download only states (Solaris 9/10.) But if it works for you,
it's not for me to comment :)
Darren
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkj8FsIACgkQP7JIXtvLbFUa3wCfUefppg8h1/POuF1clud6EGqT
f0IAn2iZDWoLgrFZIXF7fzBBrF0curbu
=4qhE
-----END PGP SIGNATURE-----
J.D. Bronson
>|> If you do "setenv CC gcc" (or "export CC=gcc), does the build succeed?
>|>
>|> Darren
>|
>| I do not run gcc nor do I have it on these machines for testing.
>| (It was not installed)
>| All programs are compiled with Studio 12.
>
>Technically, you're not supposed to be using Studio 12 on Solaris 8
>as the download only states (Solaris 9/10.) But if it works for you,
>it's not for me to comment :)
>
>Darren
I am not sure what the major confusion is here.
I am running Solaris 10. (as my post subject states) and using
Studio 12.
Certainly thats an appropriate choice :-)
The OP uses an older Solaris.
With the OPs provided patch on Sorceforge, the program compiles and
runs via Solaris 10 and Studio 12.
This patch needs to be reviewed and ideally incorporated.
BTW, the link on the ipfilter main page shows 4.1.30 for download
but yet when you click it, your given 4.1.31 but yet when that builds
it still shows as 4.1.30.
-JD
Cy Schubert
tle
.id.au>, Darren Reed writes:
> After what seems like an eternity, I've finally uploaded version
> IPFilter 5.1.1.
>
> There are no patch files for against 5.1.0 or 4.1.35 as they'd be
> too large to
> have any meaning.
>
> Building and testing has been primarily done on Solaris 10 and
> NetBSD 5.99, with no panics or crashes from regular activity.
> It should also compile and load up fine on FreeBSD as well.
> Someone asked about Illumos earlier in the week - when I last
> tried building there, I ran into some problems that seem related
> to bugs in their header files.
>
> Why should you replace version 4 with 5?
>
> At the user interface level, obscure error messages should now be
> a thing of the past when dealing with the kernel module. There are
> still likely to be obscure messages when parsing configuration
> files or in other areas, but that will be taken care of in time too.
>
> If you build IPFilter with "COMPAT_IPFILTER" defined in the top
> level Makefile, it will be possible to use ipf/ipnat from earlier
> versions of IPFilter to load a configuration but use of ipfstat
> and ipnat to display rules and statistics will run into trouble.
>
> In terms of basic features, ipnat now supports IPv6 and with new
> "rewrite" rules, both the source and destination address can be
> replaced using a single NAT rule. In addition, "divert" and
> "encap" rules have been added for experimentation.
> See the new man page ipnat(5) for more details.
>
> For ipf, it is now possible to use a filter rule group for filtering
> of ICMP packets associated with existing state entries using the
> "icmp-head" option with "keep state". Additionally, it is now
> possible to restrict the number of individual networks or hosts
> that have associated state entries, preventing a single source from
> dominating the state table. Version 5 also introduces a compeltely
> new type of rule to ipf.conf - "decapsulate". These rules make it
> possible to tell IPFilter to "remove" the headers at the front of a
> packet and process the contents as a new packet. In the short term,
> the primary application of this is to allow firewalls that are not
> a tunnel end point to filter on the traffic inside the tunnel where
> the traffic is not encrypted. See ipf.conf(5) for more details.
>
> The logging application, ipmon, can now be given a configuration
> file that allows for log entries to be stored in different files,
> delivered via syslog or via SNMP traps. See ipmon(5) for more
> details.
>
> http://coombs.anu.edu.au/~avalon/ip_fil5.1.1.tar.gz
>
> MD5 (ip_fil5.1.1.tar.gz) = e9d51c6e58f549c4ab499254c81c90d2
Thanks Darren.
As it's too new, it's probably too soon to import this into the FreeBSD src
tree. However I've started work on an IP Filter port (to be put in
security/ipfilter). It will put the kernel modules into /boot/modules
(where ports put their modules) while the userland binaries will go into
$PREFIX (usually /usr/local). Had to patch a couple of Makefiles to get the
PREFIX stuff set up (just not installing correctly yet). I spent an hour on
it last night and hope to put in a couple more hours tonight. I may have to
rename the kernel modules so as not to confuse kldload (or the user will
have to specify the fully qualified pathname or change the module loading
order via sysctl -- haven't had a chance to think about this yet).
The port will has an overwrite base option like the bind ports do however
I'm not entirely convinced this is something we need so it may be removed
before it's committed.
Of course if folks want to compile it into the base kernel, they're on
their own. The port will not support that.
I suppose once people have had a chance to use the port for a while we can
import it into base.
--
Cheers,
Cy Schubert <Cy.Sc...@komquats.com>
FreeBSD UNIX: <c...@FreeBSD.org> Web: http://www.FreeBSD.org
Darren Reed
> Thanks Darren.
>
> As it's too new, it's probably too soon to import this into the FreeBSD src
> tree. However I've started work on an IP Filter port (to be put in
> security/ipfilter). It will put the kernel modules into /boot/modules
> (where ports put their modules) while the userland binaries will go into
> $PREFIX (usually /usr/local). Had to patch a couple of Makefiles to get the
> PREFIX stuff set up (just not installing correctly yet). I spent an hour on
> it last night and hope to put in a couple more hours tonight. I may have to
> rename the kernel modules so as not to confuse kldload (or the user will
> have to specify the fully qualified pathname or change the module loading
> order via sysctl -- haven't had a chance to think about this yet).
>
> The port will has an overwrite base option like the bind ports do however
> I'm not entirely convinced this is something we need so it may be removed
> before it's committed.
>
> Of course if folks want to compile it into the base kernel, they're on
> their own. The port will not support that.
>
> I suppose once people have had a chance to use the port for a while we can
> import it into base.
Thanks,
Darren