build fixes for glibc-2.3.6 and old systems

Hi Yann,

I was trying to build a toolchain with gcc-3.4.6 +
glibc-2.3.6 using
crosstool-ng-1.1.0. My system is quite old (slackware 7
based) and
uses gcc-2.95.3. Running on such an old system reveals some
minor
bugs quite easily.

First, I noticed that some erroneous links were created
early in the
build process due to this code :

/usr/lib/ct-ng-1.1.0/scripts/crosstool.sh :

    CT_DoLog DEBUG "Making build system tools
available"
    mkdir -p "$/bin"
    for tool in ar as dlltool gcc g++ gnatbind gnatmake ld
nm ranlib strip windres objcopy objdump; do
        tmp=`CT_Which $`
        if [ -n "$" ]; then
            ln -sfv "$"
"$/bin/$-$"
            ln -sfv "$"
"$/bin/$-$"
            ln -sfv "$"
"$/bin/$-$"
        fi |CT_DoLog DEBUG
    done

It causes such broken links for non-existing tools, because
"which" returns
an error message which is part of the link target :

rwxrwxrwx  1 willy users    554 May 10 14:34
i686-build_pc-linux-gnu-dlltool -> which: no dlltool in
(/cross/i386-cross-linux-gnu/bin:/usr/src/crosstool/gcc-3.4.
6-glibc-2.3.6/targets/i386-cross-linux-gnu/build/gcc-core-sh
ared/bin:/usr/src/crosstool/gcc-3.4.6-glibc-2.3.6/targets/i3
86-cross-linux-gnu/build/gcc-core-static/bin:/var/flx-toolch
ain/i586-linux/tool-i686-host-linux/usr/bin:/usr/local/qt/bi
n:/usr/local/linuxprinter/bin:/usr/local/bin:/usr/bin:/bin:/
usr/X11R6/bin:/usr/openwin/bin:/usr/games:.:/opt/kde/bin:/us
r/share/texmf/bin:/opt/mysql/bin:/opt/mysql/sbin:/opt/palinu
x/bin:/sbin:/usr/sbin:/usr/local/sbin:/usr/local/bin)


Also, $-gcc points to the wrong gcc (/usr/bin/gcc)
instead of
$CT_CC_NATIVE. Mine (2.95) cannot build glibc-2.3.6 while
the gcc-3.3
I have in CT_CC_NATIVE can.

I noticed that binutils builds using "gcc" instead
of the $CT_CC_NATIVE.
I did not find how to fix it in the makefile or scripts, so
I temporarily
moved my /usr/bin/gcc symlink to gcc-3.3.

When installing libc headers, the wrong compiler is used
(CT_TARGET)
instead of CT_BUILD, resulting in the headers not being
built :

[ALL  ]    checking for i386-cross-linux-gnu-gcc... which:
no i386-cross-linux-gnu-gcc in
(/cross/i386-cross-linux-gnu/bin:/usr/src/crosstool/gcc-3.4.
6-glibc-2.3.6/targets/i386-cross-linux-gnu/build/g
cc-core-shared/bin:/usr/src/crosstool/gcc-3.4.6-glibc-2.3.6/
targets/i386-cross-linux-gnu/build/gcc-core-static/bin:/var/
flx-toolchain/i586-linux/tool-i686-host-linux/usr/bin:/usr/l
ocal/qt/bin:/usr/loc
al/linuxprinter/bin:/usr/local/bin:/usr/bin:/bin:/usr/X11R6/
bin:/usr/openwin/bin:/usr/games:.:/opt/kde/bin:/usr/share/te
xmf/bin:/opt/mysql/bin:/opt/mysql/sbin:/opt/palinux/bin:/sbi
n:/usr/sbin:/usr/loc
al/sbin:/usr/local/bin)
[ERROR]    checking for suffix of object files... configure:
error: cannot compute suffix of object files: cannot
compile

I fixed it with the following patch :

--- crosstool-ng-1.1.0/scripts/build/libc_glibc.sh	Sat May 
3 19:51:16 2008
+++ /usr/lib/ct-ng-1.1.0/scripts/build/libc_glibc.sh	Sat May
10 14:54:15 2008
 -83,7
+83,7 
    
addons_config="${addons_config//linuxthreads/}"
     addons_config=`echo "$" |sed
-r -e 's/^,+//; s/,+$//; s/,+/,/g;'`
 
-    cross_cc=`CT_Which "$-gcc"`
+    cross_cc=`CT_Which "$-gcc"`
     CT_DoLog DEBUG "Using gcc for target:
"$""
     CT_DoLog DEBUG "Extra config passed :
"$""
 

Last, glibc-2.3.6 does not build unless
glibc-2.3.6-csu-Makefile.patch
from crosstool SVN is applied. It seems it depends on the
bash version
used. Mine is 3.00.16(1). The patch is said to be OK for
everyone. It's
caused by "echo" not being portable, while
"printf" is more strictly
defined. You can get it here BTW :

http
://crosstool.googlecode.com/svn-history/r21/trunk/src/patche
s/glibc-2.3.6/glibc-2.3.6-csu-Makefile.patch

Otherwise, everything works great! Thanks for such a
pleasant tool!

Regards,
Willy


--
For unsubscribe information see http://sourcewar
e.org/lists.html#faq

Hello Willy!

On Saturday 10 May 2008 15:55:54 Willy Tarreau wrote:
> First, I noticed that some erroneous links were created
early in the
> build process due to this code :
[--SNIP--]
> It causes such broken links for non-existing tools,
because "which" returns
> an error message which is part of the link target :
[--SNIP--]

I see. Could you please send me the result of:
$ which non_existing_binary
$ echo $?

> Also, $-gcc points to the wrong gcc
(/usr/bin/gcc) instead of
> $CT_CC_NATIVE. Mine (2.95) cannot build glibc-2.3.6
while the gcc-3.3
> I have in CT_CC_NATIVE can.

Arggh... In fact CT_CC_NATIVE was never really tested.
Sighh... :-( It was
working once, I remember, but that must has been loooong
ago... I will have to
rework this.

> I noticed that binutils builds using "gcc"
instead of the $CT_CC_NATIVE.
> I did not find how to fix it in the makefile or
scripts, so I temporarily
> moved my /usr/bin/gcc symlink to gcc-3.3.

Tsss. binutils strike again! 

> When installing libc headers, the wrong compiler is
used (CT_TARGET)
> instead of CT_BUILD, resulting in the headers not being
built :

No, CT_TARGET _is_ to be used! The compiler gets
target-specific arguments,
so it has to be a cross-compiler.

> [ALL  ]    checking for i386-cross-linux-gnu-gcc...
which: no i386-cross-linux-gnu-gcc in
>
(/cross/i386-cross-linux-gnu/bin:/usr/src/crosstool/gcc-3.4.
6-glibc-2.3.6/targets/i386-cross-linux-gnu/build/gcc-core-sh
ared/bin:
[--SNIP--]

Could you please have a look at what is in those two
directories (split on
two lines to avoid long lines):
/usr/src/crosstool/gcc-3.4.6-glibc-2.3.6/targets/...
.../i386-cross-linux-gnu/build/gcc-core-shared/bin

and in:
/usr/src/crosstool/gcc-3.4.6-glibc-2.3.6/targets/...
.../i386-cross-linux-gnu/build/gcc-core-static/bin

> I fixed it with the following patch :
> --- crosstool-ng-1.1.0/scripts/build/libc_glibc.sh	Sat
May  3 19:51:16 2008
> +++
/usr/lib/ct-ng-1.1.0/scripts/build/libc_glibc.sh	Sat May 10
14:54:15 2008
>  -83,7 +83,7 
>     
addons_config="${addons_config//linuxthreads/}"
>      addons_config=`echo "$"
|sed -r -e 's/^,+//; s/,+$//; s/,+/,/g;'`
>  
> -    cross_cc=`CT_Which "$-gcc"`
> +    cross_cc=`CT_Which "$-gcc"`
>      CT_DoLog DEBUG "Using gcc for target:
"$""
>      CT_DoLog DEBUG "Extra config passed :
"$""

This works for you because your target is of the same kind
as your build
machine. You should have had a cross-compiler at this
step... Could send
me your full build.log (compressed)?

> Last, glibc-2.3.6 does not build unless
glibc-2.3.6-csu-Makefile.patch
> from crosstool SVN is applied.

Fixed in SVN, thanks!

> Otherwise, everything works great! Thanks for such a
pleasant tool!

Thank you for your feedback!

Regards,
Yann E. MORIN.

-- 
.-----------------.--------------------.------------------.-
-------------------.
|  Yann E. MORIN  | Real-Time Embedded | /" ASCII
RIBBON | Erics' conspiracy: |
| +0/33 662376056 | Software  Designer |  / CAMPAIGN     | 
 ^                |
| --==< °_° >==-- °------------.-------:  X  AGAINST  
   |  /e  There is no  |
| http://ymorin.is-a-geek.
org/ | * _ * | /  HTML MAIL    |  """ 
conspiracy.  |
°------------------------------°-------°------------------°-
-------------------°


--
For unsubscribe information see http://sourcewar
e.org/lists.html#faq

Hello again!

> > Also, $-gcc points to the wrong gcc
(/usr/bin/gcc) instead of
> > $CT_CC_NATIVE. Mine (2.95) cannot build
glibc-2.3.6 while the gcc-3.3
> > I have in CT_CC_NATIVE can.
> Arggh... In fact CT_CC_NATIVE was never really tested.
Sighh... :-( It was
> working once, I remember, but that must has been
loooong ago... I will have to
> rework this.

Care to have a go with the attached patch, please?

Regards,
Yann E. MORIN.

-- 
.-----------------.--------------------.------------------.-
-------------------.
|  Yann E. MORIN  | Real-Time Embedded | /" ASCII
RIBBON | Erics' conspiracy: |
| +0/33 662376056 | Software  Designer |  / CAMPAIGN     | 
 ^                |
| --==< °_° >==-- °------------.-------:  X  AGAINST  
   |  /e  There is no  |
| http://ymorin.is-a-geek.
org/ | * _ * | /  HTML MAIL    |  """ 
conspiracy.  |
°------------------------------°-------°------------------°-
-------------------°

--
For unsubscribe information see http://sourcewar
e.org/lists.html#faq

Hello Yann,

On Sun, May 11, 2008 at 01:42:12PM +0200, Yann E. MORIN
wrote:
> Hello again!
> 
> > > Also, $-gcc points to the wrong gcc
(/usr/bin/gcc) instead of
> > > $CT_CC_NATIVE. Mine (2.95) cannot build
glibc-2.3.6 while the gcc-3.3
> > > I have in CT_CC_NATIVE can.
> > Arggh... In fact CT_CC_NATIVE was never really
tested. Sighh... :-( It was
> > working once, I remember, but that must has been
loooong ago... I will have to
> > rework this.
> 
> Care to have a go with the attached patch, please?

OK, will do ASAP (most likely one evening this week).

Thanks!
Willy


--
For unsubscribe information see http://sourcewar
e.org/lists.html#faq

Heelo Yann,

sorry for the long delay. I found some time this morning for
a new test and
noticed you had released 1.1.1 which includes the patch your
asked me to
test.

On Sun, May 11, 2008 at 09:05:03AM +0200, Yann E. MORIN
wrote:
> On Saturday 10 May 2008 15:55:54 Willy Tarreau wrote:
> > First, I noticed that some erroneous links were
created early in the
> > build process due to this code :
> [--SNIP--]
> > It causes such broken links for non-existing
tools, because "which" returns
> > an error message which is part of the link target
:
> [--SNIP--]
> 
> I see. Could you please send me the result of:
> $ which non_existing_binary
> $ echo $?

$ which non_existing_binary
which: no non_existing_binary in
(/var/flx-toolchain/i586-flx-linux/tool-i686-host-linux/usr/
bin:/usr/local/qt/bin:/usr/local/linuxprinter/bin:/usr/local
/bin:/usr/bin:/bin:/usr/X11R6/bin:/usr/openwin/bin:/usr/game
s:.:/opt/kde/bin:/usr/share/texmf/bin:/opt/mysql/bin:/opt/my
sql/sbin:/opt/palinux/bin:/sbin:/usr/sbin:/usr/local/sbin:/u
sr/local/bin)
$ echo $?
1

I also see the same thing in build-libc-headers/config.log
:

CC='which: no i586-cross-linux-gnu-gcc in
(/cross/i586-gcc346-lib236/bin:/usr/src/crosstool/crosstool-
ng-1.1.1/targets/i586-cross-linux-gnu/build/gcc-core-shared/
bin:/usr/src/crosstool/crosstool-ng-1.1.1/targets/i586-cross
-linux-gnu/build/gcc-core-static/bin:/var/flx-toolchain/i586
-flx-linux/tool-i686-host-linux/usr/bin:/usr/local/qt/bin:/u
sr/local/linuxprinter/bin:/usr/local/bin:/usr/bin:/bin:/usr/
X11R6/bin:/usr/openwin/bin:/usr/games:.:/opt/kde/bin:/usr/sh
are/texmf/bin:/opt/mysql/bin:/opt/mysql/sbin:/opt/palinux/bi
n:/sbin:/usr/sbin:/usr/local/sbin:/usr/local/bin)'


> > Also, $-gcc points to the wrong gcc
(/usr/bin/gcc) instead of
> > $CT_CC_NATIVE. Mine (2.95) cannot build
glibc-2.3.6 while the gcc-3.3
> > I have in CT_CC_NATIVE can.
> 
> Arggh... In fact CT_CC_NATIVE was never really tested.
Sighh... :-( It was
> working once, I remember, but that must has been
loooong ago... I will have to
> rework this.

seems better now in 1.1.1.

> > I noticed that binutils builds using
"gcc" instead of the $CT_CC_NATIVE.
> > I did not find how to fix it in the makefile or
scripts, so I temporarily
> > moved my /usr/bin/gcc symlink to gcc-3.3.
> 
> Tsss. binutils strike again! 

It *seems* to me that in my toolchain I don't have this
problem. I'm used to
build binutils that way :

        mkdir -p $(BINUTILS_BDIR)
        (cd $(BINUTILS_BDIR) && CC=$(HOSTCC)
$(BINUTILS_SDIR)/configure 
           --host=$(HOST) --target=$(TARGET)
--prefix=$(TOOL_PREFIX) 
           --with-sysroot=$(SYS_ROOT) 
          
--with-lib-path="$(TOOL_PREFIX)/$(TARGET)-linux/lib:$(R
OOTDIR)/lib:$(ROOT_PREFIX)/lib" 
           --disable-shared --disable-locale --disable-nls

        )

Unfortunately, I don't have the build logs anymore so I
cannot check that
I don't have the same problem here.

> > When installing libc headers, the wrong compiler
is used (CT_TARGET)
> > instead of CT_BUILD, resulting in the headers not
being built :
> 
> No, CT_TARGET _is_ to be used! The compiler gets
target-specific arguments,
> so it has to be a cross-compiler.

Yes sorry, now that you're saying it, you're right of
course. In my toolchain,
I'm used to build a first-stage gcc for this purpose.

> > [ALL  ]    checking for
i386-cross-linux-gnu-gcc... which: no
i386-cross-linux-gnu-gcc in
> >
(/cross/i386-cross-linux-gnu/bin:/usr/src/crosstool/gcc-3.4.
6-glibc-2.3.6/targets/i386-cross-linux-gnu/build/gcc-core-sh
ared/bin:
> [--SNIP--]
> 
> Could you please have a look at what is in those two
directories (split on
> two lines to avoid long lines):
> /usr/src/crosstool/gcc-3.4.6-glibc-2.3.6/targets/...
> .../i386-cross-linux-gnu/build/gcc-core-shared/bin
> 
> and in:
> /usr/src/crosstool/gcc-3.4.6-glibc-2.3.6/targets/...
> .../i386-cross-linux-gnu/build/gcc-core-static/bin

yes, here they are. There's no gcc there :-(


willypcw:crosstool-ng-1.1.1$ ll
targets/i586-cross-linux-gnu/build/gcc-core-shared/i586-cros
s-linux-gnu/bin/
total 0
drwxr-xr-x  2 willy users 144 May 20 06:19 ./
drwxr-xr-x  3 willy users  72 May 20 06:19 ../
lrwxrwxrwx  1 willy users  53 May 20 06:19 ar ->
/cross/i586-gcc346-lib236/bin/i586-cross-linux-gnu-ar*
lrwxrwxrwx  1 willy users  53 May 20 06:19 as ->
/cross/i586-gcc346-lib236/bin/i586-cross-linux-gnu-as*
lrwxrwxrwx  1 willy users  53 May 20 06:19 ld ->
/cross/i586-gcc346-lib236/bin/i586-cross-linux-gnu-ld*
lrwxrwxrwx  1 willy users  56 May 20 06:19 strip ->
/cross/i586-gcc346-lib236/bin/i586-cross-linux-gnu-strip*
willypcw:crosstool-ng-1.1.1$ ll
targets/i586-cross-linux-gnu/build/gcc-core-static/i586-cros
s-linux-gnu/bin/
total 0
drwxr-xr-x  2 willy users 144 May 20 06:19 ./
drwxr-xr-x  3 willy users  72 May 20 06:19 ../
lrwxrwxrwx  1 willy users  53 May 20 06:19 ar ->
/cross/i586-gcc346-lib236/bin/i586-cross-linux-gnu-ar*
lrwxrwxrwx  1 willy users  53 May 20 06:19 as ->
/cross/i586-gcc346-lib236/bin/i586-cross-linux-gnu-as*
lrwxrwxrwx  1 willy users  53 May 20 06:19 ld ->
/cross/i586-gcc346-lib236/bin/i586-cross-linux-gnu-ld*
lrwxrwxrwx  1 willy users  56 May 20 06:19 strip ->
/cross/i586-gcc346-lib236/bin/i586-cross-linux-gnu-strip*

It may be a makefile dependency issue, because I notice that
gcc has not
been built yet before libc-headers are built. The following
order is observed
in build.log :
  - tar x
  - patch
  - install kernel headers
  - build binutils
  - build libc-headers => fail

It's clear to me that a cc_core build is missing before
libc-headers. I have
saved the build.log if you want it.

I tried to force the build to restart with gcc, but I got an
error, maybe
I'm not using it correctly :

willypcw:crosstool-ng-1.1.1$ ./ct-ng cc_core_pass_1  
[INFO ]  Build started 20080520.065646
[INFO ]  Checking environment sanity
[INFO ]  Building environment variables
[EXTRA]  Preparing working directories
[ERROR]  The previous build did not reach the point where it
could be restarted at "cc_core_pass_1"
[00:00] / make[1]: *** [build] Error 1
make: *** [cc_core_pass_1] Error 2

> This works for you because your target is of the same
kind as your build
> machine. You should have had a cross-compiler at this
step... Could send
> me your full build.log (compressed)?

Yes, I'm sending it to you in a second mail in order not to
pollute the list.

Regards,
Willy


--
For unsubscribe information see http://sourcewar
e.org/lists.html#faq

Hello again!

On Saturday 10 May 2008 15:55:54 Willy Tarreau wrote:
> When installing libc headers, the wrong compiler is
used (CT_TARGET)
> instead of CT_BUILD, resulting in the headers not being
built :

You're not going with linuxthreads, are you?

Building linuxthreads-based glibc is broken, as you just
pointed out. Only
NPTL works (or should work) with glibc. It's a crosstool-NG
limitation so
far.

In the case of NPTL, a cross-compiler, C-only, bare compiler
is built before
the C library headers get installed. So we have a
cross-compiler by that
time.

But in the case of linuxthreads, that X-compiler is not
built. So we can't use
it to build necessary C library. Where it becomes quite
strange (IMPOV) is that
linuxthreads *should* *not* require that compiler. Anyway,
it didn't when
crosstool-NG didn't support building NPTL. Since the time I
introduced NPTL
support, the linuxthreads builds broke.

Seems you just pointed me at the correct line, here! 

> I fixed it with the following patch :
> -    cross_cc=`CT_Which "$-gcc"`
> +    cross_cc=`CT_Which "$-gcc"`

Will be a bit more complex than just that, we'll just test
wether we're
going NPTL or linuxthreads, and set the compiler
accordingly.

This will have to wait a little bit, I have other,
ARM-BE-EABI-uClibc problems
ATM.

Regards,
Yann E. MORIN.

-- 
.-----------------.--------------------.------------------.-
-------------------.
|  Yann E. MORIN  | Real-Time Embedded | /" ASCII
RIBBON | Erics' conspiracy: |
| +0/33 662376056 | Software  Designer |  / CAMPAIGN     | 
 ^                |
| --==< °_° >==-- °------------.-------:  X  AGAINST  
   |  /e  There is no  |
| http://ymorin.is-a-geek.
org/ | * _ * | /  HTML MAIL    |  """ 
conspiracy.  |
°------------------------------°-------°------------------°-
-------------------°


--
For unsubscribe information see http://sourcewar
e.org/lists.html#faq

Hi Yann,

On Thu, May 22, 2008 at 11:53:52PM +0200, Yann E. MORIN
wrote:
> Hello again!
> 
> On Saturday 10 May 2008 15:55:54 Willy Tarreau wrote:
> > When installing libc headers, the wrong compiler
is used (CT_TARGET)
> > instead of CT_BUILD, resulting in the headers not
being built :
> 
> You're not going with linuxthreads, are you?

yes I am !

> Building linuxthreads-based glibc is broken, as you
just pointed out. Only
> NPTL works (or should work) with glibc. It's a
crosstool-NG limitation so
> far.

OK, I understand now why we had different behaviours.

> In the case of NPTL, a cross-compiler, C-only, bare
compiler is built before
> the C library headers get installed. So we have a
cross-compiler by that
> time.
> 
> But in the case of linuxthreads, that X-compiler is not
built. So we can't use
> it to build necessary C library. Where it becomes quite
strange (IMPOV) is that
> linuxthreads *should* *not* require that compiler.
Anyway, it didn't when
> crosstool-NG didn't support building NPTL. Since the
time I introduced NPTL
> support, the linuxthreads builds broke.
> 
> Seems you just pointed me at the correct line, here!

> 
> > I fixed it with the following patch :
> > -    cross_cc=`CT_Which
"$-gcc"`
> > +    cross_cc=`CT_Which
"$-gcc"`
> 
> Will be a bit more complex than just that, we'll just
test wether we're
> going NPTL or linuxthreads, and set the compiler
accordingly.
> 
> This will have to wait a little bit, I have other,
ARM-BE-EABI-uClibc problems
> ATM.

No problem, I don't need it right now anyway. As I said, I
already have my
own toolchain for my needs, but am always interested in
seeing what exists.
I must say I like the ability to configure crosstool-NG as
it is now, and
will still be following its development. But don't waste
your time on my
bug report if nobody else complains.

Regards
Willy


--
For unsubscribe information see http://sourcewar
e.org/lists.html#faq

* Yann E. MORIN <yann.morin.1998anciens.enib.fr> wrote:

> Building linuxthreads-based glibc is broken, as you
just pointed out. Only
> NPTL works (or should work) with glibc. It's a
crosstool-NG limitation so
> far.

Ugh, can we fix it somehow ?
I'm maintaining a bunch of old (even 2.4 kernel) system and
like to use
a crosscompiler for this.

> But in the case of linuxthreads, that X-compiler is not
built. So we can't use
> it to build necessary C library. Where it becomes quite
strange (IMPOV) is that
> linuxthreads *should* *not* require that compiler.
Anyway, it didn't when
> crosstool-NG didn't support building NPTL. Since the
time I introduced NPTL
> support, the linuxthreads builds broke.

hmm, do you have an idea where this break comes from ?


cu
-- 
------------------------------------------------------------
---------
 Enrico Weigelt    ==   metux IT service - http://www.metux.de/
------------------------------------------------------------
---------
 Please visit the OpenSource QM Taskforce:
 	h
ttp://wiki.metux.de/public/OpenSource_QM_Taskforce
 Patches / Fixes for a lot dozens of packages in dozens of
versions:
	http://patches.metux.de/

------------------------------------------------------------
---------

--
For unsubscribe information see http://sourcewar
e.org/lists.html#faq

Enrico,
All,

On Saturday 24 May 2008 01:55:45 Enrico Weigelt wrote:
> * Yann E. MORIN <yann.morin.1998anciens.enib.fr> wrote:
> > Building linuxthreads-based glibc is broken, as
you just pointed out. Only
> > NPTL works (or should work) with glibc. It's a
crosstool-NG limitation so
> > far.
> Ugh, can we fix it somehow ?

Yes, fixing is planned.

> > the linuxthreads builds broke.
> hmm, do you have an idea where this break comes from ?

I have an idea, yes. But I don't have time to
investigate/comnfirm it right
now... Later in the WE.

If you wish, you can see whre Willy just pointed, and set
this conditionaly.
If we're NPTL, use a cross-compiler, if not we have to
decide/find what to
use...

Regards,
Yann E. MORIN.

-- 
.-----------------.--------------------.------------------.-
-------------------.
|  Yann E. MORIN  | Real-Time Embedded | /" ASCII
RIBBON | Erics' conspiracy: |
| +0/33 662376056 | Software  Designer |  / CAMPAIGN     | 
 ^                |
| --==< °_° >==-- °------------.-------:  X  AGAINST  
   |  /e  There is no  |
| http://ymorin.is-a-geek.
org/ | * _ * | /  HTML MAIL    |  """ 
conspiracy.  |
°------------------------------°-------°------------------°-
-------------------°


--
For unsubscribe information see http://sourcewar
e.org/lists.html#faq