gcc segfault at src/mman/mlockall.c

gcc segfault at src/mman/mlockall.c

[Isaac Dunham]

With -Os -fno-stack-protector, gcc (Ubuntu 4.4.3-4ubuntu5.1) 4.4.3
gcc -std=c99 -nostdinc -ffreestanding -ffloat-store
-frounding-math -D_XOPEN_SOURCE=700 -I./src/internal -I./include
-I./arch/i386  -pipe -fno-unwind-tables -fno-asynchronous-unwind-tables
-fomit-frame-pointer -falign-functions=1 -falign-labels=1
-falign-loops=1 -falign-jumps=1 -march=i486 -mtune=generic -Os
-fno-stack-protector -c -o src/mman/mlockall.o src/mman/mlockall.c 
cc1: internal compiler error: Segmentation fault 
Please submit a full bug report, with preprocessed source if
appropriate. See <file:///usr/share/doc/gcc-4.4/README.Bugs> for
instructions. 
make: *** [src/mman/mlockall.o] Error 1

gcc=latest gcc-4.4 package from Ubuntu

With -O3, I get 
===
gcc -std=c99 -nostdinc -ffreestanding -ffloat-store -frounding-math
-D_XOPEN_SOURCE=700 -I./src/internal -I./include -I./arch/i386  -pipe
-fno-unwind-tables -fno-asynchronous-unwind-tables -fomit-frame-pointer
-falign-functions=1 -falign-labels=1 -falign-loops=1 -falign-jumps=1
-march=i486 -mtune=generic -O3 -fno-stack-protector -c -o
src/misc/getgrouplist.o src/misc/getgrouplist.c 
cc1: internal compiler error: Segmentation fault 
Please submit a full bug report, with preprocessed source if
appropriate. See <file:///usr/share/doc/gcc-4.4/README.Bugs> for
instructions. 
make: *** [src/misc/getgrouplist.o] Error 1
===
Switching over to gcc-4.1, since I've used that without errors.

Re: gcc segfault at src/mman/mlockall.c

[Isaac Dunham]

On Tue, 15 May 2012 09:35:53 -0700
Isaac Dunham <idunham@lavabit.com> wrote:
[using gcc-4.4, the standard with Ubuntu 10.04, segfaults]
> Switching over to gcc-4.1, since I've used that without errors.
gcc-4.1 works.


By the way, would there be an option to change the gcc version used by
musl-gcc? (ie, use gcc=gcc-4.1)

Isaac Dunham

Re: gcc segfault at src/mman/mlockall.c

[Szabolcs Nagy]

* Isaac Dunham <idunham@lavabit.com> [2012-05-15 09:42:36 -0700]:
> By the way, would there be an option to change the gcc version used by
> musl-gcc? (ie, use gcc=gcc-4.1)
> 

maybe -V worksm try
musl-gcc -V 4.1 --version
vs
musl-gcc -V 4.4 --version

Re: gcc segfault at src/mman/mlockall.c

[Szabolcs Nagy]

* Szabolcs Nagy <nsz@port70.net> [2012-05-15 21:21:04 +0200]:
> maybe -V worksm try
> musl-gcc -V 4.1 --version

i could try it meanwhile, it works but --version does not :)
so you can use
CC='musl-gcc -V 4.1'

Re: gcc segfault at src/mman/mlockall.c

[Isaac Dunham]

On Tue, 15 May 2012 21:30:53 +0200
Szabolcs Nagy <nsz@port70.net> wrote:

> * Szabolcs Nagy <nsz@port70.net> [2012-05-15 21:21:04 +0200]:
> > maybe -V worksm try
> > musl-gcc -V 4.1 --version
> 
> i could try it meanwhile, it works but --version does not :)
> so you can use
> CC='musl-gcc -V 4.1'
same situation here
but when you just told it the version to use, why ask?

By the way, would you have pointers on using pcc with musl?
Is it possible to use it as a glibc -> musl cross-compiler ?
..seems that the official "cross-compiler" method might work for
that...if binutils doesn't pose a problem.

Re: gcc segfault at src/mman/mlockall.c

[Szabolcs Nagy]

* Isaac Dunham <idunham@lavabit.com> [2012-05-16 11:53:41 -0700]:
> On Tue, 15 May 2012 21:30:53 +0200
> > i could try it meanwhile, it works but --version does not :)
> > so you can use
> > CC='musl-gcc -V 4.1'
> same situation here
> but when you just told it the version to use, why ask?
just to see if -V really worked :)

> By the way, would you have pointers on using pcc with musl?
> Is it possible to use it as a glibc -> musl cross-compiler ?
> ..seems that the official "cross-compiler" method might work for
> that...if binutils doesn't pose a problem.

i'm not sure what is a glibc->musl cross-compiler

i used something like the following to compile with pcc using musl libc

MUSL=/path/to/musl
PCC=`pcc -v foobar.o 2>&1 |sed -n 's,.* \([^ ]*\)/lib/crtbegin.o.*,\1,p'`

x.o: x.c
	pcc $(CFLAGS) -nostdinc -isystem $(MUSL)/include -isystem $(PCC)/include -c -o $@ $<
x-static1: x.o
	ld -X -d -e _start -Bstatic -o $@ $< $(LDFLAGS) $(MUSL)/lib/crti.o $(MUSL)/lib/crt1.o \
	  $(PCC)/lib/crtbegin.o $(PCC)/lib/crtend.o $(MUSL)/lib/crtn.o -L$(MUSL)/lib -lc -L$(PCC)/lib -lpcc
x-static2: x.o
	pcc -static -nostdlib -o $@ $< $(LDFLAGS) $(MUSL)/lib/crti.o $(MUSL)/lib/crt1.o \
	  $(PCC)/lib/crtbegin.o $(PCC)/lib/crtend.o $(MUSL)/lib/crtn.o -L$(MUSL)/lib -lc -L$(PCC)/lib -lpcc
x-dynamic1: x.o
	ld -X -d -e _start -dynamic-linker /lib/ld-musl-i386.so.1 -o $@ $< $(LDFLAGS) $(MUSL)/lib/crti.o $(MUSL)/lib/crt1.o \
	  $(PCC)/lib/crtbegin.o $(PCC)/lib/crtend.o $(MUSL)/lib/crtn.o -L$(MUSL)/lib -lc -L$(PCC)/lib -lpcc
x-dynamic2: x.o
	pcc -nostdlib -Wl,-dynamic-linker,/lib/ld-musl-i386.so.1 -o $@ $< $(LDFLAGS) $(MUSL)/lib/crti.o $(MUSL)/lib/crt1.o \
	  $(PCC)/lib/crtbegin.o $(PCC)/lib/crtend.o $(MUSL)/lib/crtn.o -L$(MUSL)/lib -lc -L$(PCC)/lib -lpcc


if you want to compile musl itself with pcc
iirc you only have to change -lgcc into -lpcc
in the Makefile

Re: gcc segfault at src/mman/mlockall.c

[Isaac Dunham]

On Thu, 17 May 2012 00:04:57 +0200
Szabolcs Nagy <nsz@port70.net> wrote:

> i'm not sure what is a glibc->musl cross-compiler
Built on glibc, targets musl (similar to musl-gcc, though a strict
cross-compiler is a little more complex)
> i used something like the following to compile with pcc using musl
> libc

> MUSL=/path/to/musl
> PCC=`pcc -v foobar.o 2>&1 |sed -n 's,.*
> \([^ ]*\)/lib/crtbegin.o.*,\1,p'`
> 
> x.o: x.c
> 	pcc $(CFLAGS) -nostdinc -isystem $(MUSL)/include -isystem
> $(PCC)/include -c -o $@ $< x-static1: x.o
> 	ld -X -d -e _start -Bstatic -o $@ $< $(LDFLAGS)
> $(MUSL)/lib/crti.o $(MUSL)/lib/crt1.o \ $(PCC)/lib/crtbegin.o
> $(PCC)/lib/crtend.o $(MUSL)/lib/crtn.o -L$(MUSL)/lib -lc -L$(PCC)/lib
> -lpcc x-static2: x.o pcc -static -nostdlib -o $@ $< $(LDFLAGS)
> $(MUSL)/lib/crti.o $(MUSL)/lib/crt1.o \ $(PCC)/lib/crtbegin.o
> $(PCC)/lib/crtend.o $(MUSL)/lib/crtn.o -L$(MUSL)/lib -lc -L$(PCC)/lib
> -lpcc x-dynamic1: x.o ld -X -d -e _start
> -dynamic-linker /lib/ld-musl-i386.so.1 -o $@ $< $(LDFLAGS)
> $(MUSL)/lib/crti.o $(MUSL)/lib/crt1.o \ $(PCC)/lib/crtbegin.o
> $(PCC)/lib/crtend.o $(MUSL)/lib/crtn.o -L$(MUSL)/lib -lc -L$(PCC)/lib
> -lpcc x-dynamic2: x.o pcc -nostdlib
> -Wl,-dynamic-linker,/lib/ld-musl-i386.so.1 -o $@ $< $(LDFLAGS)
> $(MUSL)/lib/crti.o $(MUSL)/lib/crt1.o \ $(PCC)/lib/crtbegin.o
> $(PCC)/lib/crtend.o $(MUSL)/lib/crtn.o -L$(MUSL)/lib -lc -L$(PCC)/lib
> -lpcc

For static, I can do it about like so (shell):
# Pass 1: headers
pcc $@ -nostdinc -isystem $MUSL/include -isystem $PCC/include
# Pass 2: linking executables
STARTOBJ="$MUSL/lib/crti.o $MUSL/lib/crt1.o $PCC/lib/crtbegin.o"
ENDOBJ="$PCC/lib/crtend.o $MUSL/lib/crtn.o -L$MUSL/lib -lc -L$PCC/lib \
 -lpcc"
pcc -nostdlib -static $STARTOBJ $@ $ENDOBJ

Thanks!
Isaac Dunham

Re: gcc segfault at src/mman/mlockall.c

[Jens Staal]

2012/5/17 Szabolcs Nagy <nsz@port70.net>:
> if you want to compile musl itself with pcc
> iirc you only have to change -lgcc into -lpcc
> in the Makefile
>


Very cool, so with obase-musl [1] and pcc self-hosting on musl, we
would only need the BSDfund challenge [2] to compile Linux with pcc to
have a self-hosting system with only permissive stuff in userland :)

[1] https://github.com/chneukirchen/obase/tree/musl
[2] http://bsdfund.org/bundle/

Re: gcc segfault at src/mman/mlockall.c

[Christian Neukirchen]

Jens Staal <staal1978@gmail.com> writes:

> 2012/5/17 Szabolcs Nagy <nsz@port70.net>:
>> if you want to compile musl itself with pcc
>> iirc you only have to change -lgcc into -lpcc
>> in the Makefile
>>
>
>
> Very cool, so with obase-musl [1] and pcc self-hosting on musl, we
> would only need the BSDfund challenge [2] to compile Linux with pcc to
> have a self-hosting system with only permissive stuff in userland :)
>
> [1] https://github.com/chneukirchen/obase/tree/musl
> [2] http://bsdfund.org/bundle/

obase-musl still lacks a lot due to many legacy syscalls musl probably
won't implement.

-- 
Christian Neukirchen  <chneukirchen@gmail.com>  http://chneukirchen.org

Re: gcc segfault at src/mman/mlockall.c

[Jens Staal]

[-- Attachment #1: Type: text/plain, Size: 204 bytes --]

> obase-musl still lacks a lot due to many legacy syscalls musl probably
> won't implement.
>
> --
> Christian Neukirchen  <chneukirchen@gmail.com>  http://chneukirchen.org

Could libbsd help with those?

[-- Attachment #2: Type: text/html, Size: 360 bytes --]

Re: gcc segfault at src/mman/mlockall.c

[Kurt H Maier]

On Fri, May 18, 2012 at 08:43:33PM +0200, Jens Staal wrote:
> > obase-musl still lacks a lot due to many legacy syscalls musl probably
> > won't implement.
> >
> > --
> > Christian Neukirchen  <chneukirchen@gmail.com>  http://chneukirchen.org
> 
> Could libbsd help with those?

Is it really worth adding on more and more cruft just to get a base
system working?  In my opinion it would be better to flesh out sbase[1]
or something like it.  Requiring a compatibility shim for your core
utilities sounds like a bad day waiting to happen.

[1] - http://hg.suckless.org/sbase

Re: gcc segfault at src/mman/mlockall.c

[Rich Felker]

On Fri, May 18, 2012 at 02:51:23PM -0400, Kurt H Maier wrote:
> On Fri, May 18, 2012 at 08:43:33PM +0200, Jens Staal wrote:
> > > obase-musl still lacks a lot due to many legacy syscalls musl probably
> > > won't implement.
> > >
> > > --
> > > Christian Neukirchen  <chneukirchen@gmail.com>  http://chneukirchen.org
> > 
> > Could libbsd help with those?
> 
> Is it really worth adding on more and more cruft just to get a base
> system working?  In my opinion it would be better to flesh out sbase[1]
> or something like it.  Requiring a compatibility shim for your core
> utilities sounds like a bad day waiting to happen.

If there are really _syscalls_ not implemented, I'd be interested in
knowing what they are. There's really no cost to adding syscall
wrappers. If it's a matter of library functions though, then yes, I'd
agree. If using obase is desirable, it would be best to patch out the
non-portable stuff in obase, or if that's too difficult, use libbsd
(hopefully an improved version; in its current form, it seems very
broken and like gnulib has a lot of #error in the #else cases).

By the way, sbase in its current form is not much of an option. As far
as I can tell, the only way its tools "suck less" is in the area of
bloat; in the area of actually working correctly, they leave A LOT to
be desired. For example, at a first glance, grep lacks support for
multiple regexes (either on the command line with -e or
newline-separated, or from a file with -f). This kind of
non-conformance will badly break all sorts of shell scripts, including
possibly configure scripts (thus making it impossible to build any
software).

There is also my noXCUse package, which aims at complete conformance
in all commands implemented, but not many commands are implemented
yet.

Rich

Re: gcc segfault at src/mman/mlockall.c

[Kurt H Maier]

On Fri, May 18, 2012 at 06:58:45PM -0400, Rich Felker wrote:
> 
> By the way, sbase in its current form is not much of an option. As far
> as I can tell, the only way its tools "suck less" is in the area of
> bloat; in the area of actually working correctly, they leave A LOT to
> be desired.


Hence "flesh out" rather than "deploy."

Re: gcc segfault at src/mman/mlockall.c

[Isaac Dunham]

On Fri, 18 May 2012 18:58:45 -0400
Rich Felker <dalias@aerifal.cx> wrote:
> > On Fri, May 18, 2012 at 08:43:33PM +0200, Jens Staal wrote:
> > > > obase-musl still lacks a lot due to many legacy syscalls musl
> > > > probably won't implement.
> > > >
> > > Could libbsd help with those?
..
> There's really no cost to adding syscall
> wrappers. If it's a matter of library functions though, then yes, I'd
> agree. If using obase is desirable, it would be best to patch out the
> non-portable stuff in obase, or if that's too difficult, use libbsd
> (hopefully an improved version; in its current form, it seems very
> broken and like gnulib has a lot of #error in the #else cases).
I ought to try compiling libbsd again...
 
> By the way, sbase in its current form is not much of an option. As far
> as I can tell, the only way its tools "suck less" is in the area of
> bloat; in the area of actually working correctly, they leave A LOT to
> be desired. For example, at a first glance, grep lacks support for
> multiple regexes (either on the command line with -e or
> newline-separated, or from a file with -f). This kind of
> non-conformance will badly break all sorts of shell scripts, including
> possibly configure scripts (thus making it impossible to build any
> software).
> 
> There is also my noXCUse package, which aims at complete conformance
> in all commands implemented, but not many commands are implemented
> yet.
Had not heard of that one, and Google seems not to recognize it... Is it
publicly available yet?

While we're enumerating permissively-licensed userspaces, we might as
well remember Android's toolbox, and more relevantly toybox (Landley's
project that set off the whole discussion of licensing).
And in the less-viable set of options, there's beastiebox (way too
limited and BSD-specific, though it may compile on Linux),
and somewhere I saw a git repo with a port of netbsd userspace to
uclibc (incompatible with musl, of course--uclibc seems to be the most
"legacy friendly" libc in terms of headers, even compared with glibc).
Besides that there's heirloom-tools.
That would make 8 packages under permissive licenses that aim at what
you're talking about.
So it isn't like there's a lack of options, it's just that none of
them seem to be ready at present.
By the way, make is probably one of the biggest limitations--Linux and
musl both rely extensively on gmake features that none of the
BSD/permissively-licensd make versions support yet.  You probably won't
get the kernel policy changed, either.

Isaac Dunham

Re: gcc segfault at src/mman/mlockall.c

[Rich Felker]

On Fri, May 18, 2012 at 05:45:33PM -0700, Isaac Dunham wrote:
> > There is also my noXCUse package, which aims at complete conformance
> > in all commands implemented, but not many commands are implemented
> > yet.
> Had not heard of that one, and Google seems not to recognize it... Is it
> publicly available yet?

It's on git.etalabs.net. I didn't put any effort into the release;
it's mostly code I had around from years ago. Only grep is new. Here's
the gitweb link:

http://git.etalabs.net/cgi-bin/gitweb.cgi

> While we're enumerating permissively-licensed userspaces, we might as

Actually mine are still GPL or LGPL (I forget which), but I have no
objection to relicensing them. I can do it sometime soon if anybody's
interested.

> well remember Android's toolbox,

Somehow I doubt this works at all...

> and more relevantly toybox (Landley's
> project that set off the whole discussion of licensing).

Yes, toybox is quite interesting but incomplete. In the long term it's
probably going to be the best option, though, especially if Rob ends
up being responsive about issues that come up... (Like my recent
finding that xargs is doing what many ppl wrongly assume it does,
rather than what it's actually supposed to do.)

> And in the less-viable set of options, there's beastiebox (way too
> limited and BSD-specific, though it may compile on Linux),
> and somewhere I saw a git repo with a port of netbsd userspace to
> uclibc (incompatible with musl, of course--uclibc seems to be the most
> "legacy friendly" libc in terms of headers, even compared with glibc).
> Besides that there's heirloom-tools.
> That would make 8 packages under permissive licenses that aim at what
> you're talking about.

But how many of them aim to implement POSIX compatible utilities, and
of those, how many come close to succeeding? Tools that are rough
lookalikes/workalikes for the standard tools but which behave
differently in subtle ways are rather useless for the purpose of
running third-party scripts (including configure scripts).

> So it isn't like there's a lack of options, it's just that none of
> them seem to be ready at present.

I agree there are several options, but not quite as many as you think.

> By the way, make is probably one of the biggest limitations--Linux and
> musl both rely extensively on gmake features that none of the
> BSD/permissively-licensd make versions support yet.  You probably won't
> get the kernel policy changed, either.

GNU make is by far the best/only decent make. If anybody really cares
that much about permissive license, they're free to make a clone, but
since GNU make is self-contained, extremely portable, clean code, I
think refusing to use it on the basis of license is silly. It's not
like other GNU packages that give you plenty of technical reasons to
dislike them in addition to whatever your ideological reasons are.

Rich

Re: noXCUse, userspace options

[Isaac Dunham]

On Fri, 18 May 2012 20:56:55 -0400
Rich Felker <dalias@aerifal.cx> wrote:

> On Fri, May 18, 2012 at 05:45:33PM -0700, Isaac Dunham wrote:
> > > There is also my noXCUse package, which aims at complete
> > > conformance in all commands implemented, but not many commands
> > > are implemented yet.
> > Had not heard of that one, and Google seems not to recognize it...
> > Is it publicly available yet?
> 
> It's on git.etalabs.net. I didn't put any effort into the release;
> it's mostly code I had around from years ago. Only grep is new. Here's
> the gitweb link:
> 
> http://git.etalabs.net/cgi-bin/gitweb.cgi
> 
> > While we're enumerating permissively-licensed userspaces...
> Actually mine are still GPL or LGPL (I forget which), but I have no
> objection to relicensing them. I can do it sometime soon if anybody's
> interested.
I'd assumed that it was permissively-licensed because you mentioned it
in a thread that started with:
|Very cool, so with obase-musl [1] and pcc self-hosting on musl, we
|would only need the BSDfund challenge [2] to compile Linux with pcc to
|have a self-hosting system with only permissive stuff in userland :)

Your call on license.  But if the discussion is about a
permissively-licensed userspace, mentioning a GPL one seems a bit odd.

> > well remember Android's toolbox,
> Somehow I doubt this works at all...
Enough to boot Android, that's all.  I guess strike that.
> > and more relevantly toybox (Landley's
> > project that set off the whole discussion of licensing).
> Yes, toybox is quite interesting but incomplete. In the long term it's
> probably going to be the best option, though, especially if Rob ends
> up being responsive about issues that come up... (Like my recent
> finding that xargs is doing what many ppl wrongly assume it does,
> rather than what it's actually supposed to do.)

> > And in the less-viable set of options, there's beastiebox (way too
> > limited and BSD-specific, though it may compile on Linux),
> > and somewhere I saw a git repo with a port of netbsd userspace to
> > uclibc (incompatible with musl, of course--uclibc seems to be the
> > most "legacy friendly" libc in terms of headers, even compared with
> > glibc). Besides that there's heirloom-tools.
> > That would make 8 packages under permissive licenses that aim at
> > what you're talking about.
> 
> But how many of them aim to implement POSIX compatible utilities, and
> of those, how many come close to succeeding? Tools that are rough
> lookalikes/workalikes for the standard tools but which behave
> differently in subtle ways are rather useless for the purpose of
> running third-party scripts (including configure scripts).
Implement POSIXish utilities: at least the NetBSD utilities,
heirloom (they have multiple personalities, one being xpg).
Aim at POSIX-like: those plus obase (by virtue of bing a port of
OpenBSD's usrspace, which is fairly close to conformant)
Farther upthread, it was indicated that the goal isn't a POSIX
userspace, but a self-hosting one.
> > So it isn't like there's a lack of options, it's just that none of
> > them seem to be ready at present.
> I agree there are several options, but not quite as many as you think.
Option: project aims to provide something that could be used for a
self-hosting permissively-licensed userspace, as per the quote I
referred to. Full POSIX/SUS4 conformance is not mandatory, as long as
builds work.
Ready: usable at present for a self-hosting environment.
In other words, "Plenty of projects aim to be usable for this, but few
of them are."

> > By the way, make is probably one of the biggest limitations--Linux
> > and musl both rely extensively on gmake features that none of the
> > BSD/permissively-licensd make versions support yet.  You probably
> > won't get the kernel policy changed, either. 
> GNU make is by far the best/only decent make. If anybody really cares
> that much about permissive license, they're free to make a clone, but
> since GNU make is self-contained, extremely portable, clean code, I
> think refusing to use it on the basis of license is silly...
The person who started this discussion was talking about a permissively
licensed userspace.  While I agree that a fully permissive userspace
isn't really sensible, I thought I'd best clarify that they're
underestimating the work.

Isaac Dunham

Re: noXCUse grep

[Isaac Dunham]

On Fri, 18 May 2012 20:56:55 -0400
Rich Felker <dalias@aerifal.cx> wrote:

> On Fri, May 18, 2012 at 05:45:33PM -0700, Isaac Dunham wrote:
> > > There is also my noXCUse package, which aims at complete
> > > conformance in all commands implemented, but not many commands
> > > are implemented yet.
> > Had not heard of that one, and Google seems not to recognize it...
> > Is it publicly available yet?
> 
> It's on git.etalabs.net. I didn't put any effort into the release;
> it's mostly code I had around from years ago. Only grep is new. Here's
> the gitweb link:
> 
> http://git.etalabs.net/cgi-bin/gitweb.cgi
By the way, I was trying to build pcc and configure failed at grep,
when I used noXCUse grep (but not with busybox grep)--the test was for
a grep version  supporting long lines and -e, IIRC.

Re: gcc segfault at src/mman/mlockall.c

[Christian Neukirchen]

Rich Felker <dalias@aerifal.cx> writes:

> On Fri, May 18, 2012 at 02:51:23PM -0400, Kurt H Maier wrote:
>> On Fri, May 18, 2012 at 08:43:33PM +0200, Jens Staal wrote:
>> > > obase-musl still lacks a lot due to many legacy syscalls musl probably
>> > > won't implement.
>> > >
>> > > --
>> > > Christian Neukirchen  <chneukirchen@gmail.com>  http://chneukirchen.org
>> > 
>> > Could libbsd help with those?
>> 
>> Is it really worth adding on more and more cruft just to get a base
>> system working?  In my opinion it would be better to flesh out sbase[1]
>> or something like it.  Requiring a compatibility shim for your core
>> utilities sounds like a bad day waiting to happen.
>
> If there are really _syscalls_ not implemented, I'd be interested in
> knowing what they are.

Sorry, not syscalls; I mean BSD libc functions such as fts(3).

-- 
Christian Neukirchen  <chneukirchen@gmail.com>  http://chneukirchen.org