[leaf-user] Snort on uCllibc
We have just upgraded our firewall from a 2+ year old Bering floppy on an old 486 to a uClibc 2.3-rc1 box with CF. Among other things I have setup Snort, the 2.2 version that came on the ISO image for 2.3-rc1. Q1: Does anyone have a more recent version of Snort available for uClibc? Q2: Does anyone running Snort on a Bering box have any pointers or tips from their experience? I only have it looking at the outside interface with tcp-dump and CSV logging. Thanks, Richard Amerman --- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl leaf-user mailing list: leaf-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-user Support Request -- http://leaf-project.org/
Re: [leaf-user] gcc 4.0
Hi Paul, > I'm not complaining, mind you, just reporting the facts: > gcc 4.0 will not build binutils 2.14 but does build 2.16.1 fine > gcc 4.0 will not build gcc 3.3 (have not investigated further) > > This is going to be a bit of a support issue moving forward, so it would > be a good thing (tm) to add support for alternate versions of the host > compiler in your makefiles (HOST compiler, not TARGET compiler), > -or- > upgrade our build environment to not include code that doesn't break in > gcc 4.0 (either by switching the target compiler to something newer, or > by just fixing line 653 in read-rtl.c of gcc 3.3.3. Right now, when > buildtool bootstraps itself, it assumes the host compiler is just "gcc" > -- it would be nice if we could specify something trivial to buildtool > to run gcc-3.4 instead. Point taken - tweaking the makefiles to allow for specifying a different host compiler than "gcc" sounds like a good idea (I was assuming that simply setting CC=whatever would actually do the trick, but I've never tried it). Regarding your suggestion about changing the buildenv to build with gcc 4.x - if gcc 4.0 will not build gcc 3.3.2, we're out of luck anyway (regarding a quick and simple solution) - as Eric pointed out, there are several sources that break when one tries to compile them with anything later than gcc 3.3.3 (I tried 3.3.4 and failed, I don't even want to imagine how they behave with gcc 4.0.x) - busybox and bash are the ones I stumbled over, when trying to upgrade (see revisions 1.12 and 1.13 of src/bering-uclibc/apps/buildenv/buildtool.mk for "proof" :-)). That's why we still use gcc 3.3.3, despite the fact that gcc 3.3.6/3.4.4/4.0.2 are out. Yes, it would be possible to upgrade all of those problematic sources too, but if we do that, I guess we might as well skip Bering uClibc 2.3 and go right ahead to Bering uClibc 2.4 (since we'd have to upgrade several packages in the process, which would basically require starting from scratch with the beta cycle). I'm not saying it's impossible - it just seems like the timing is not quite ideal for making a change like that right now. But as I said, tweaking the makefiles for buildenv to allow specifying a different compiler than "gcc" could be the way to go. Just my two cents (I'll most likely be using gcc-3.4.3 for the next several years as my "HOST compiler", so I might not be terribly qualified to work on that anyway). Martin --- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl leaf-user mailing list: leaf-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-user Support Request -- http://leaf-project.org/
Re: [leaf-user] gcc 4.0
FWIW, this appears to possibly be a bug in gcc 4.0:
Sorry to follow up to myself again, I missed some #defines elsewhere.
This is NOT a gcc 4.0 bug. Gcc 3.3.3 was playing fast and loose with
assumptions about what you could do incrementing void **'s and gcc-4.0
tightens that up. The code in obstack.h was rewritten in gcc 3.4 and
no longer makes those assumptions.
I suspect that upgrading the target compiler to gcc 3.4 will solve these
problems, but if we're going to do that, we'd be stupid to not just
upgrade to gcc 4.0 and get the pain over with once and for all. I can
put together a patch to fix gcc 3.3.3, but right now, not having a
working leaf build environment isn't ruining my day, so I may just wait
for someone else to suffer.
FWIW, the code in question in obstack.h uses constructs of the type:
*((void **)__o->next_free)++ = ((void *)datum);
which was rewritten in gcc 3.4 to be:
{ struct obstack *__o1 = (OBSTACK);
*(const void **) __o1->next_free = (aptr);
__o1->next_free += sizeof (const void *);
(void) 0; }
These bad pointer arithmetic operations are unfortunately littered
throughout obstack.h in various forms, hence my lack of desire to fix.
I hope these notes help someone.
Paul
---
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
leaf-user mailing list: leaf-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/leaf-user
Support Request -- http://leaf-project.org/
[leaf-user] e100 driver update?
Just wondering if anyone has an update to the e100 driver (Intel PRO NIC cards)? I tried to compile the latest one from Intel's site but when I tried using it in bering uclibc the driver gave some stack dump. Is there a document on how to compile drivers? --Mark --- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl leaf-user mailing list: leaf-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-user Support Request -- http://leaf-project.org/
Re: [leaf-user] gcc 4.0
I realize that, but what I'm saying is that right now, the build
enviornment ITSELF can't be built with gcc 4.0. I'm not interested in
upgrading the target compiler yet, rather, I can no longer build the
tools like the target compiler anymore because gcc 4.0 won't build
gcc 3.3.
I'm not complaining, mind you, just reporting the facts:
gcc 4.0 will not build binutils 2.14 but does build 2.16.1 fine
gcc 4.0 will not build gcc 3.3 (have not investigated further)
This is going to be a bit of a support issue moving forward, so it would
be a good thing (tm) to add support for alternate versions of the host
compiler in your makefiles (HOST compiler, not TARGET compiler), -or-
upgrade our build environment to not include code that doesn't break in
gcc 4.0 (either by switching the target compiler to something newer, or
by just fixing line 653 in read-rtl.c of gcc 3.3.3. Right now, when
buildtool bootstraps itself, it assumes the host compiler is just "gcc"
-- it would be nice if we could specify something trivial to buildtool
to run gcc-3.4 instead.
FWIW, this appears to possibly be a bug in gcc 4.0:
gcc -c -g -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes
-Wmissing-prototypes -Wtraditional -pedantic -Wno-long-long
-DHAVE_CONFIG_H -DGENERATOR_FILE-I. -I.
-I/home/pst/bering-uclibc/buildtool/source/buildenv/gcc-3.3.3/gcc
-I/home/pst/bering-uclibc/buildtool/source/buildenv/gcc-3.3.3/gcc/.
-I/home/pst/bering-uclibc/buildtool/source/buildenv/gcc-3.3.3/gcc/config
-I/home/pst/bering-uclibc/buildtool/source/buildenv/gcc-3.3.3/gcc/../include
/home/pst/bering-uclibc/buildtool/source/buildenv/gcc-3.3.3/gcc/read-rtl.c
-o read-rtl.o
In file included from
/home/pst/bering-uclibc/buildtool/source/buildenv/gcc-3.3.3/gcc/read-rtl.c:24:
/home/pst/bering-uclibc/buildtool/source/buildenv/gcc-3.3.3/gcc/rtl.h:132:
warning: type of bit-field 'code' is a GCC extension
/home/pst/bering-uclibc/buildtool/source/buildenv/gcc-3.3.3/gcc/rtl.h:135:
warning: type of bit-field 'mode' is a GCC extension
/home/pst/bering-uclibc/buildtool/source/buildenv/gcc-3.3.3/gcc/read-rtl.c:
In function 'fatal_with_file_and_line':
/home/pst/bering-uclibc/buildtool/source/buildenv/gcc-3.3.3/gcc/read-rtl.c:53:
warning: traditional C rejects ISO C style function definitions
/home/pst/bering-uclibc/buildtool/source/buildenv/gcc-3.3.3/gcc/read-rtl.c:
In function 'read_rtx':
/home/pst/bering-uclibc/buildtool/source/buildenv/gcc-3.3.3/gcc/read-rtl.c:653:
error: invalid lvalue in increment
make[2]: *** [read-rtl.o] Error 1
make[2]: Leaving directory
`/home/pst/bering-uclibc/buildtool/source/buildenv/gcc-initial/gcc'
make[1]: *** [all-gcc] Error 2
case 'E':
{
/* Obstack to store scratch vector in. */
struct obstack vector_stack;
int list_counter = 0;
rtvec return_vec = NULL_RTVEC;
c = read_skip_spaces (infile);
if (c != '[')
fatal_expected_char (infile, '[', c);
/* add expressions to a list, while keeping a count */
obstack_init (&vector_stack);
while ((c = read_skip_spaces (infile)) && c != ']')
{
ungetc (c, infile);
list_counter++;
obstack_ptr_grow (&vector_stack, (PTR) read_rtx (infile));
}
if (list_counter > 0)
{
return_vec = rtvec_alloc (list_counter);
memcpy (&return_vec->elem[0], obstack_finish (&vector_stack),
list_counter * sizeof (rtx));
}
XVEC (return_rtx, i) = return_vec;
obstack_free (&vector_stack, NULL);
/* close bracket gotten */
}
break;
Line 653 is the call to obstack_ptr_grow, it really is a function,
as is read_rtx, so I don't see an lvalue to increment. The previous
line, list_counter's increment, is just an int.
Sigh.
Paul
---
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
leaf-user mailing list: leaf-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/leaf-user
Support Request -- http://leaf-project.org/
