ipcop-devel Mailing List for IPCop Firewall

On 12/27/2010 10:33 PM, Vinod Nadiadwala wrote:
> Hello,
>          I am using ipcop 1.4.0 with 100 users and having 2 MBPS 
> bandwidth connected to the ipcop red interface other users are 
> connected on green, also using Advanced Proxy addon,  i would like to 
> restrict upload & downloaded speed of specific client based on ip / 
> mac address, if anybody know solution on this issue or if there is any 
> commercial module / support available for development of such feature 
> i am ready to donate please help !!!
>
> * I know about advanced QoS, so don't suggest the same, as i expecting 
> something else.
>
>
>
> Vinod

Depending on what you're using in the AdvancedProxy add-on you may be 
able to do this as well.  You can restrict bandwidth per host on both 
green and blue, but it applies to all general hosts.  Unrestricted hosts 
appear to bypass this.  If you aren't already using both restricted and 
unrestricted hosts you could provide this function by having only the 
desired machine in the restricted group.  Otherwise you'll probably have 
to do it directly with iptables.  Using the rules created by 
AdvancedProxy to do the general restrictions should give you a starting 
point as to methodology, then have the rule applied only if the IP or 
MAC matches you target.

Melvin

Hello,
         I am using ipcop 1.4.0 with 100 users and having 2 MBPS bandwidth
connected to the ipcop red interface other users are connected on green,
also using Advanced Proxy addon,  i would like to restrict upload &
downloaded speed of specific client based on ip / mac address, if anybody
know solution on this issue or if there is any commercial module / support
available for development of such feature i am ready to donate please help
!!!

* I know about advanced QoS, so don't suggest the same, as i expecting
something else.



Vinod

Selon Olaf Westrik <wei...@ip...>:

> On 2010-12-25 08:50, Gilles Espinasse wrote:
>
> > We may try with ccache-3.1.2, using a new environment variable created for
> > that.
>
> That's a good idea.
> Also if we stick with using export for CCACHE_* environment variables,
> we do not need to pass them in toolchain_make and chroot_make, and can
> drop the null-cache-prefix patch.
>
>
> > Something like this should work and cover specs change or (mostly) a patch
> > in the compiler.
> >
> > CCACHE_COMPILERCHECK=%compiler% -dumpspecs;size %compiler%
> >
> > No more patch should be needed. (specs file include the compiler version)
> >
> > A patch to the compiler may not change the compiler size, we may prefer to
> > hash the compiler.
>
> Not sure about hashes. That would take time for every call of ccache/gcc
> would it not?
> How about we check for gcc version and size only? Combined with cleaning
> ccache when we rebuild toolchain or use make.sh gettoolchain?
>
>
> Olaf
>
Using hash for compiler and specs file would not take time if we calculate only
the hash once and send that value to ipcop-gcc-hash file or variable and set
CCACHE_COMPILERCHECK={cat or echo} ipcop-gcc-ash

That should not be very slower than the default CACHE_COMPILERCHECK=mtime that
check size and mtime and faster than CACHE_COMPILERCHECK=content that hash the
compiler content at each call.


I have fixed a few issue on my lfs/gcc diff. I prefer that way because we test
really the code we compile but changing back to unhardened specs is not enought.
There is still much more errors than with unpatched gcc for hardening.

gcc test is still running.


Gilles

Thanks to the Spanish translators we now have Danish, English, French,
German, Greek, Italian, Turkish, Spanish and Dutch all complete for
IPCop v2.0.

Behind them we have Russian and Spanish Latino at 81% complete, with
Brazilian Portuguese, Swedish, Norwegian, Portuguese, Slovak and Czech
just behind  them.

Vietnamese, Chinese Simplified, Chinese Traditional, Polish, Finnish,
Hungarian, Somali, Japanese are between 50 to 66% complete.

Arabic, Afrikaans, Slovenian, Bulgarian, Catalan, Romanian, Urdu,
Persian, Lithuanian, Gujurati and Thai need a lot of work done.

If anybody is looking for a small project over the holidays, and are
comfortable with the technical language involved, please let me know
if you'd like to contribute. If you have already translated an
ipcop.po file or a .pl file from v1.4.x into your own language we
_can_ upload them to the Language Database, saving a lot of cutting
and pasting, providing the files are in UTF-8 format.

We don't expect you to be able to do it all, or know every phrase. The
IPCop Project is a Team Effort. If you wanted to pick a small area,
like all the phrases used in the menus, or on one particular cgi page,
that all helps.

Thanks again to all our Translators.

Eric

On 2010-12-25 08:50, Gilles Espinasse wrote:

> We may try with ccache-3.1.2, using a new environment variable created for
> that.

That's a good idea.
Also if we stick with using export for CCACHE_* environment variables, 
we do not need to pass them in toolchain_make and chroot_make, and can 
drop the null-cache-prefix patch.


> Something like this should work and cover specs change or (mostly) a patch
> in the compiler.
>
> CCACHE_COMPILERCHECK=%compiler% -dumpspecs;size %compiler%
>
> No more patch should be needed. (specs file include the compiler version)
>
> A patch to the compiler may not change the compiler size, we may prefer to
> hash the compiler.

Not sure about hashes. That would take time for every call of ccache/gcc 
would it not?
How about we check for gcc version and size only? Combined with cleaning 
ccache when we rebuild toolchain or use make.sh gettoolchain?


Olaf

Gilles Espinasse wrote:

> Selon David W Studeman <avi...@ai...>:
> 
> 
>> >
>> The latest commit with the ccache patch and subsequent correction commit
>> builds fine on OpenSuSE 11.3 X86_64 and it also installs cleanly from
>> booting the iso.
>>
>> --
>> Dave
>> http://www.raqcop.com
>>
> 
> I am testing the attached diff for gcc.
> Then I will try ccache-3 upgrade, probably tomorrow
> 
> 
> Gilles
> 
Very good. This would be about six years newer. 

-- 
Dave
http://www.raqcop.com

Selon David W Studeman <avi...@ai...>:


> >
> The latest commit with the ccache patch and subsequent correction commit
> builds fine on OpenSuSE 11.3 X86_64 and it also installs cleanly from
> booting the iso.
>
> --
> Dave
> http://www.raqcop.com
>

I am testing the attached diff for gcc.
Then I will try ccache-3 upgrade, probably tomorrow


Gilles

Gilles Espinasse wrote:

> 
> ----- Original Message -----
> From: "Olaf Westrik" <wei...@ip...>
> To: "Gilles Espinasse" <g....@fr...>
> Cc: <ipc...@li...>
> Sent: Friday, December 24, 2010 12:47 PM
> Subject: Re: [IPCop-devel] Fw:[Ipcop-svn] SF.net SVN:
> ipcop:[5243]ipcop/trunk/config/gcc/specs-iso
> 
> 
>> On 2010-12-24 10:50, Gilles Espinasse wrote:
>>
>> >> The only thing I can think of that might be different is that my build
>> >> box is running 32 bit Debian.
>> >>
>> > I have made the test on a same debian 5.0 32 bits.
>>
>> Yesterday I installed a completely fresh Debian 5.07 64 bits. I started
>> everything from scratch (no cache, no ccache, no toolchain), build has
>> now arrived at openssl, without problems.
>> So I do not understand what could be different.
>>
>>
>> Olaf
> 
> We have one hack in ccache, in that we don't hash on the compiler
> modification time.
> The reason is simply that we recompile the compiler each time, so there
> would be a new modification time at each gcc compilation and that would
> invalidate the ccache usage.
> 
> Looking more at ccache code, specs are not include in the hash normaly,
> only when using --specs option, so each time we play with the specs with a
> direct change, we are in the road of a wrong ccache result.
> 
> Gilles
> 
The latest commit with the ccache patch and subsequent correction commit 
builds fine on OpenSuSE 11.3 X86_64 and it also installs cleanly from 
booting the iso.

-- 
Dave
http://www.raqcop.com

Hi,
ledtrig-netdev is a very useful kernel module which provides viewing 
activity of network devices, specially on headless boxes.
Here's a patch for recent kernel:
http://www.gknw.net/test/ipcop/linux-2.6.32_ledtrig-morse+netdev.patch.txt
the patch also includes ledtrig-morse which might be useful too on 
headless boxes for signaling error conditions.
Both modules are very small:
-rw-r--r-- 1 root root 2240 Nov 23 05:53 ledtrig-morse.ko.gz
-rw-r--r-- 1 root root 3205 Nov 23 05:53 ledtrig-netdev.ko.gz

please consider to add at least ledtrig-netdev to the ipcop builds.

Thanks, Gün.

----- Original Message ----- 
From: "Gilles Espinasse" <g....@fr...>
To: "Olaf Westrik" <wei...@ip...>
Cc: <ipc...@li...>
Sent: Saturday, December 25, 2010 6:29 AM
Subject: Re: [IPCop-devel] Fw:[Ipcop-svn] SF.net SVN:
ipcop:[5243]ipcop/trunk/config/gcc/specs-iso


>
> ----- Original Message ----- 
> From: "Olaf Westrik" <wei...@ip...>
> To: "Gilles Espinasse" <g....@fr...>
> Cc: <ipc...@li...>
> Sent: Friday, December 24, 2010 12:47 PM
> Subject: Re: [IPCop-devel] Fw:[Ipcop-svn] SF.net SVN:
> ipcop:[5243]ipcop/trunk/config/gcc/specs-iso
>
>
> > On 2010-12-24 10:50, Gilles Espinasse wrote:
> >
> > >> The only thing I can think of that might be different is that my
build
> > >> box is running 32 bit Debian.
> > >>
> > > I have made the test on a same debian 5.0 32 bits.
> >
> > Yesterday I installed a completely fresh Debian 5.07 64 bits. I started
> > everything from scratch (no cache, no ccache, no toolchain), build has
> > now arrived at openssl, without problems.
> > So I do not understand what could be different.
> >
> >
> > Olaf
>
> We have one hack in ccache, in that we don't hash on the compiler
> modification time.
> The reason is simply that we recompile the compiler each time, so there
> would be a new modification time at each gcc compilation and that would
> invalidate the ccache usage.
>
> Looking more at ccache code, specs are not include in the hash normaly,
only
> when using --specs option, so each time we play with the specs with a
direct
> change, we are in the road of a wrong ccache result.
>
We may try with ccache-3.1.2, using a new environment variable created for
that.

Something like this should work and cover specs change or (mostly) a patch
in the compiler.

CCACHE_COMPILERCHECK=%compiler% -dumpspecs;size %compiler%

No more patch should be needed. (specs file include the compiler version)

A patch to the compiler may not change the compiler size, we may prefer to
hash the compiler.
But that cost time to do that at each compilation, we may give to
CCACHE_COMPILERCHECK the content of a precompiled hash, something like this
as gcc does not look to include a timestamp
md5sum <path>gcc >compiler-hash
gcc -dumpversion >>compiler-hash

Then we could use
CCACHE_COMPILERCHECK=echo compiler-hash

Gilles

----- Original Message ----- 
From: "Olaf Westrik" <wei...@ip...>
To: "Gilles Espinasse" <g....@fr...>
Cc: <ipc...@li...>
Sent: Friday, December 24, 2010 12:47 PM
Subject: Re: [IPCop-devel] Fw:[Ipcop-svn] SF.net SVN:
ipcop:[5243]ipcop/trunk/config/gcc/specs-iso


> On 2010-12-24 10:50, Gilles Espinasse wrote:
>
> >> The only thing I can think of that might be different is that my build
> >> box is running 32 bit Debian.
> >>
> > I have made the test on a same debian 5.0 32 bits.
>
> Yesterday I installed a completely fresh Debian 5.07 64 bits. I started
> everything from scratch (no cache, no ccache, no toolchain), build has
> now arrived at openssl, without problems.
> So I do not understand what could be different.
>
>
> Olaf

We have one hack in ccache, in that we don't hash on the compiler
modification time.
The reason is simply that we recompile the compiler each time, so there
would be a new modification time at each gcc compilation and that would
invalidate the ccache usage.

Looking more at ccache code, specs are not include in the hash normaly, only
when using --specs option, so each time we play with the specs with a direct
change, we are in the road of a wrong ccache result.

Gilles

Eric Oberlander wrote:

> On 24 December 2010 11:47, Olaf Westrik
> <wei...@ip...> wrote:
>> On 2010-12-24 10:50, Gilles Espinasse wrote:
>>
>>>> The only thing I can think of that might be different is that my build
>>>> box is running 32 bit Debian.
>>>>
>>> I have made the test on a same debian 5.0 32 bits.
>>
>> Yesterday I installed a completely fresh Debian 5.07 64 bits. I started
>> everything from scratch (no cache, no ccache, no toolchain), build has
>> now arrived at openssl, without problems.
>> So I do not understand what could be different.
> 
> Olaf
> 
> I was building on a Ubunto 10.4 box, and I eventually deleted the
> ccache directory and it's contents.
> 
> Build has now gone past bash and is continuing...
> 
> Eric
> 
Deleting the toolchain and ccache allowed it to build no problem but now I 
can't install it.

-- 
Dave
http://www.raqcop.com

Eric Oberlander wrote:
> On 24 December 2010 11:47, Olaf Westrik <wei...@ip...> wrote:
>> On 2010-12-24 10:50, Gilles Espinasse wrote:
>>
>>>> The only thing I can think of that might be different is that my build
>>>> box is running 32 bit Debian.
>>>>
>>> I have made the test on a same debian 5.0 32 bits.
>> Yesterday I installed a completely fresh Debian 5.07 64 bits. I started
>> everything from scratch (no cache, no ccache, no toolchain), build has
>> now arrived at openssl, without problems.
>> So I do not understand what could be different.
> 
> Olaf
> 
> I was building on a Ubunto 10.4 box, and I eventually deleted the
> ccache directory and it's contents.
> 
> Build has now gone past bash and is continuing...
> 
> Eric

Deleting my ccache contents and will see if it works over here with all 
of the latest SVN updates as well.

Probably be a few hours before I report back as I have to go out, but I 
will let you guys know if it works on my Ubuntu Hardy

Darren

On 24 December 2010 11:47, Olaf Westrik <wei...@ip...> wrote:
> On 2010-12-24 10:50, Gilles Espinasse wrote:
>
>>> The only thing I can think of that might be different is that my build
>>> box is running 32 bit Debian.
>>>
>> I have made the test on a same debian 5.0 32 bits.
>
> Yesterday I installed a completely fresh Debian 5.07 64 bits. I started
> everything from scratch (no cache, no ccache, no toolchain), build has
> now arrived at openssl, without problems.
> So I do not understand what could be different.

Olaf

I was building on a Ubunto 10.4 box, and I eventually deleted the
ccache directory and it's contents.

Build has now gone past bash and is continuing...

Eric

----- Original Message ----- 
From: "Olaf Westrik" <wei...@ip...>
To: "Gilles Espinasse" <g....@fr...>
Cc: <ipc...@li...>
Sent: Friday, December 24, 2010 12:47 PM
Subject: Re: [IPCop-devel] Fw:[Ipcop-svn] SF.net SVN:
ipcop:[5243]ipcop/trunk/config/gcc/specs-iso


> On 2010-12-24 10:50, Gilles Espinasse wrote:
>
> >> The only thing I can think of that might be different is that my build
> >> box is running 32 bit Debian.
> >>
> > I have made the test on a same debian 5.0 32 bits.
>
> Yesterday I installed a completely fresh Debian 5.07 64 bits. I started
> everything from scratch (no cache, no ccache, no toolchain), build has
> now arrived at openssl, without problems.
> So I do not understand what could be different.
>
>
> Olaf
To be able to build, I am forced to use either
svn diff lfs/gcc
Index: lfs/gcc
===================================================================
--- lfs/gcc     (révision 5269)
+++ lfs/gcc     (copie de travail)
@@ -232,9 +232,9 @@
 endif

        # From HLFS, apply these 3 patches if you want to create/verify gcc
specs file
-       #cd $(DIR_APP) && patch -Np1 -i
$(DIR_PATCHES)/gcc-4.4.5_fortify-source-1.patch
-       #cd $(DIR_APP) && patch -Np1 -i
$(DIR_PATCHES)/gcc-4.4.5_fpie-1.patch
-       #cd $(DIR_APP) && patch -Np1 -i
$(DIR_PATCHES)/gcc-4.4.5_fstack-protector-1.patch
+       cd $(DIR_APP) && patch -Np1 -i
$(DIR_PATCHES)/gcc-4.4.5_fortify-source-1.patch
+       cd $(DIR_APP) && patch -Np1 -i $(DIR_PATCHES)/gcc-4.4.5_fpie-1.patch
+       cd $(DIR_APP) && patch -Np1 -i
$(DIR_PATCHES)/gcc-4.4.5_fstack-protector-1.patch

        cd $(DIR_SRC)/gcc-build &&                              \
                ../$(THISAPP)/configure                         \
or
 svn diff lfs/gcc
Index: lfs/gcc
===================================================================
--- lfs/gcc     (révision 5271)
+++ lfs/gcc     (copie de travail)
@@ -286,9 +289,9 @@

        # Make hardening the default through specs file.
        # If we patch as in HLFS, we add many errors in tests.
-       sed -e 's|GCCVERSION|$(VER)|' \
-               $(DIR_SRC)/config/gcc/specs-iso-$(MACHINE) \
-               > `dirname
$$($(TARGET_TGT)-gcc -print-libgcc-file-name)`/specs
+       #sed -e 's|GCCVERSION|$(VER)|' \
+       #       $(DIR_SRC)/config/gcc/specs-iso-$(MACHINE) \
+       #       > `dirname
$$($(TARGET_TGT)-gcc -print-libgcc-file-name)`/specs
 endif # base

        @rm -rf $(DIR_APP) $(DIR_SRC)/gcc-build

Don't look too much at the details of the second diff (revision and line
numbers), I have removed for clarity a change on pass2 (saving gcc-pass2
specs, so we could always rebuild toolchain without sed abuse)

Maybe the issue is ccache related?
I haven't run tests in both cases as I know gcc tests wil fail on the
hardened case and I was only interested for a clean log in the non-hardened
case.

Using the first variant, my build is now finished once I work around CnxADLS
and wanpipe breakage. I will look at check_files result and add more tests.

Using the second, build was successfull (there is no hardening at gcc
level), I am rebuilding with PARALISM=1 to be able to diff the log at the
next time.

Anyway I have a solution that is to test gcc without hacking the specs (but
fixing the test suite using debian fixes)

I have reviewed gcc-4.4 debian patches.
I intend to add some notes in doc/compilation design

Here is the list of patches, I annoted with yes
 svn-updates   yes for 4.4 branch update
 gcc-hash-style-gnu  yes reduce the overhead of having both hash style,
should not hurt
 libstdc++-pic    yes, will help reduce initramfs
 alpha-no-ev4-directive  yes
 note-gnu-stack   yes , used for gcc's crt files, libffi and boehm-gc
 sparc-force-cpu   yes
 pr43323    yes
 gcc-default-format-security yes
 gcc-default-fortify-source yes
 gcc-default-relro  yes
 testsuite-hardening-format yes
 testsuite-hardening-fortify yes
 testsuite-hardening-printf-types yes
 gcc-default-ssp   yes
 alpha-ieee   yes
That mean 15 patches that we would ideally load from debian web interface
and add in our objects list

Adding the alt patch that break the build on always_overflow should a good
idea
http://sisyphus.ru/en/srpm/Sisyphus/gcc4.4/patches/4

gentoo and alt link with as-needed by default.
I may try the gcc patch that do that too.

I first need to check I can apply the selected list of patches.
ThenI will try to build and run the test suite.

I have a supplement of debian maybe patches that require some testings, will
try first without
 gcc-no-add-needed  maybe : trigger failure if all needed lib are not
provided to the linker
 boehm-gc-getnprocs  maybe gc is garbage collector
 pr25509    maybe : add new option -Wno-unused-result
 libgomp-omp_h-multilib  maybe : Fix up omp.h for multilibs
 libstdc++-test-installed maybe : Add support to run the libstdc++-v3
testsuite using the installed shared libraries.
 libsupc++-vmi_class_type_info maybe : Update
libsupc++/vmi_class_type_info.cc from the 4.5 branch.

As a side note, this should explain why mklibs fail to reduce some libs in
initramfs
http://wiki.debian.org/ToolChain/DSOLinking
that should be some linking issues

the gnupg TEXTREL issue is fixed on gentoo (some sed -i -e
's:PIC:__PIC__:' )
http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/app-crypt/gnupg/gnupg-1.4.11.ebuild?revision=1.7&view=markup

That doesn't work the same because we add CFLAGS="$(CFLAGS) -fPIE -pie" to
./configure.
But if we don't add that, build fail with
creating a DT_TEXTREL in a shared object

Could be fixed once the gcc patches are changed.

Gilles

On 2010-12-24 10:50, Gilles Espinasse wrote:

>> The only thing I can think of that might be different is that my build
>> box is running 32 bit Debian.
>>
> I have made the test on a same debian 5.0 32 bits.

Yesterday I installed a completely fresh Debian 5.07 64 bits. I started 
everything from scratch (no cache, no ccache, no toolchain), build has 
now arrived at openssl, without problems.
So I do not understand what could be different.


Olaf

----- Original Message ----- 
From: "Olaf Westrik" <wei...@ip...>
To: <ipc...@li...>
Cc: "Gilles Espinasse" <g....@fr...>
Sent: Friday, December 24, 2010 7:29 AM
Subject: Re: [IPCop-devel] Fw:[Ipcop-svn] SF.net SVN:
ipcop:[5243]ipcop/trunk/config/gcc/specs-iso


> On 2010-12-24 03:36, Gilles Espinasse wrote:
>
> > I think I understand what happen.
> > The way it is actually coded, Olaf patch gcc to produce hardened specs.
But
> > as a hardened gcc fail some parts of the test suite, those patches are
> > commented by default and after the tests, the hardened specs, registred
on
> > our tree are given to gcc. This work for Olaf but not for us because the
> > produced gcc is different : Olaf apply the gcc patches.
>
> Well yes, but I have rebuild toolchain, without the gcc patches, several
> times since I created the specs file.
>
the issue is only on gcc final stage with gcc patches

> The only thing I can think of that might be different is that my build
> box is running 32 bit Debian.
>
I have made the test on a same debian 5.0 32 bits.

It build fine once gcc hardening tests are applied until CnxADLS where it
stop with an error
In function 'memset',
    inlined from 'DoAutoLogPoll' at cnxadslautolog.c:347:
/usr/include/bits/string3.h:86: error: call to __builtin___memset_chk will
always overflow destination buffer
make[1]: *** [cnxadslautolog.o] Error 1

I work around that for now using GCC_TOLERATE_ALWAYS_OVERFLOW=1

Gilles

On 2010-12-24 03:36, Gilles Espinasse wrote:

> I think I understand what happen.
> The way it is actually coded, Olaf patch gcc to produce hardened specs. But
> as a hardened gcc fail some parts of the test suite, those patches are
> commented by default and after the tests, the hardened specs, registred on
> our tree are given to gcc. This work for Olaf but not for us because the
> produced gcc is different : Olaf apply the gcc patches.

Well yes, but I have rebuild toolchain, without the gcc patches, several 
times since I created the specs file.

The only thing I can think of that might be different is that my build 
box is running 32 bit Debian.


Olaf

----- Original Message ----- 
From: "Gilles Espinasse" <g....@fr...>
To: <da...@kd...>; "Olaf Westrik" <wei...@ip...>
Cc: <ipc...@li...>
Sent: Friday, December 24, 2010 3:36 AM
Subject: Re: [IPCop-devel] Fw:[Ipcop-svn] SF.net SVN:
ipcop:[5243]ipcop/trunk/config/gcc/specs-iso


>
> ----- Original Message ----- 
> From: "Darren Critchley" <da...@kd...>
> To: "Olaf Westrik" <wei...@ip...>
> Cc: <ipc...@li...>
> Sent: Thursday, December 23, 2010 4:01 PM
> Subject: Re: [IPCop-devel] Fw:[Ipcop-svn] SF.net SVN:
> ipcop:[5243]ipcop/trunk/config/gcc/specs-iso
>
>
> > Olaf Westrik wrote:
> > > On 2010-12-23 11:02, David W Studeman wrote:
> > >
> > >>> I also just noticed that bash will not build. Probably because of
> > >>> missing CFLAGS option in zlib. Not sure why my continuous building
and
> > >>> retesting did not catch that :-(
> > >>>
> >
> > I am still having same issue, build box is Ubuntu Hardy.
> >
> > Is there anything from logs or whatever that I can supply to you guys to
> > help diagnose the problem?
> >
> > Regards
> > Darren
> >
> I think I understand what happen.
> The way it is actually coded, Olaf patch gcc to produce hardened specs.
But
> as a hardened gcc fail some parts of the test suite, those patches are
> commented by default and after the tests, the hardened specs, registred on
> our tree are given to gcc. This work for Olaf but not for us because the
> produced gcc is different : Olaf apply the gcc patches.
> HLFS fortify-source patch is a mix of 2 subjects and not only modify the
> specs, but too the gcc code.
>
I have proven I was right.
I have build two versions :
- one without the gcc patches and the specs change that will be the
reference log before hardening
- one with gcc hardening patches that build bash without issues
So the bash issue was really using non patched gcc with hardened specs
produced from a patched gcc.


Gilles

----- Original Message ----- 
From: "Darren Critchley" <da...@kd...>
To: "Olaf Westrik" <wei...@ip...>
Cc: <ipc...@li...>
Sent: Thursday, December 23, 2010 4:01 PM
Subject: Re: [IPCop-devel] Fw:[Ipcop-svn] SF.net SVN:
ipcop:[5243]ipcop/trunk/config/gcc/specs-iso


> Olaf Westrik wrote:
> > On 2010-12-23 11:02, David W Studeman wrote:
> >
> >>> I also just noticed that bash will not build. Probably because of
> >>> missing CFLAGS option in zlib. Not sure why my continuous building and
> >>> retesting did not catch that :-(
> >>>
>
> I am still having same issue, build box is Ubuntu Hardy.
>
> Is there anything from logs or whatever that I can supply to you guys to
> help diagnose the problem?
>
> Regards
> Darren
>
I think I understand what happen.
The way it is actually coded, Olaf patch gcc to produce hardened specs. But
as a hardened gcc fail some parts of the test suite, those patches are
commented by default and after the tests, the hardened specs, registred on
our tree are given to gcc. This work for Olaf but not for us because the
produced gcc is different : Olaf apply the gcc patches.
HLFS fortify-source patch is a mix of 2 subjects and not only modify the
specs, but too the gcc code.

When I was thinking to use non-hardened specs for the tests, I was more
thinking of some sed to remove from our patched gcc specs the supplement.
Anyway in this hackish world, we should prefer to use some proven way to
build and not re-invent our own wheel. I will look what I can do and maybe
patch like debian (debian fix the test suite used against an hardened gcc).

Gilles

Olaf Westrik wrote:
> On 2010-12-23 11:02, David W Studeman wrote:
> 
>>> I also just noticed that bash will not build. Probably because of
>>> missing CFLAGS option in zlib. Not sure why my continuous building and
>>> retesting did not catch that :-(
>>>

I am still having same issue, build box is Ubuntu Hardy.

Is there anything from logs or whatever that I can supply to you guys to 
help diagnose the problem?

Regards
Darren

On 2010-12-23 11:02, David W Studeman wrote:

>> I also just noticed that bash will not build. Probably because of
>> missing CFLAGS option in zlib. Not sure why my continuous building and
>> retesting did not catch that :-(
>>
>> Stay tuned.
>>
>>
>> Olaf
>>
> Confirmed here too I take it that you see this too?  /usr/bin/ld: warning:
> creating a DT_TEXTREL in a shared object.
>
> The new toolchain built fine on a OpenSuSE 11.3 X86_64 machine as expected.

The bash not building problem is gone for me. Eric and Gilles still see 
the same error as you.
We are trying to find the differences.


Olaf

Olaf Westrik wrote:

> On 2010-12-21 10:04, David W Studeman wrote:
> 
>> OT: Olaf, you metioned Annex B cards at some point in my forum I think. I
>> noticed Linitx.com showed a B model Viking but no date when they will get
>> them in. Their price on the Viking is about half what I paid for mine and
>> even less than an Actiontec I got three years ago. Of course in my case
>> it's dollars for pounds.
> 
> Indeed. Traverse itself does not mention Annex B
> http://www.traverse.com.au/productview.php?product_id=115, I'll have to
> ask them about chance to have stock in 2011.
> 
> 
> Olaf
> 

Speaking of Traverse, I wonder if Guy Ellis ever reads this list anymore? 
I see his name under copyright in pppsetup.cgi. 
-- 
Dave
http://www.raqcop.com

Olaf Westrik wrote:

> On 2010-12-22 07:57, Gilles Espinasse wrote:
> 
>>> I just checked the ppc spec and file is really very different, just
>> looking
>>> at the size only
>>> ls -l gcc*
>>> -rw-r--r-- 1 root root  4699 Dec 21 20:04 gcc-i486.specs
>>> -rw-r--r-- 1 root root 14942 Dec 21 21:02 gcc-ppc.specs
> 
> OK. I'll prepare modifications to be able to use specs file per
> architecture.
> 
> I also just noticed that bash will not build. Probably because of
> missing CFLAGS option in zlib. Not sure why my continuous building and
> retesting did not catch that :-(
> 
> Stay tuned.
> 
> 
> Olaf
> 
Confirmed here too I take it that you see this too?  /usr/bin/ld: warning: 
creating a DT_TEXTREL in a shared object.

The new toolchain built fine on a OpenSuSE 11.3 X86_64 machine as expected. 

-- 
Dave
http://www.raqcop.com

On 2010-12-22 07:57, Gilles Espinasse wrote:

>> I just checked the ppc spec and file is really very different, just
> looking
>> at the size only
>> ls -l gcc*
>> -rw-r--r-- 1 root root  4699 Dec 21 20:04 gcc-i486.specs
>> -rw-r--r-- 1 root root 14942 Dec 21 21:02 gcc-ppc.specs

OK. I'll prepare modifications to be able to use specs file per 
architecture.

I also just noticed that bash will not build. Probably because of 
missing CFLAGS option in zlib. Not sure why my continuous building and 
retesting did not catch that :-(

Stay tuned.


Olaf