> i don't know what you are doing, but it's hard to imagine
> that two libcs (or libpthreads) would work in the same
> process: if they can run code on the same thread they

This is how dlmopen() as implemented currently works (and I have had
games like openarena and dungeon defenders working with this setup).

There's currently no way _not_ to have two mappings of libc when using
dlmopen (and they each have their own mmaps and separate heaps and so
forth, so it mostly works).

For example, here are the link maps when running glxgears with this
exact setup:

(dl-handle CAPSULE // the private dlmopen namespace
   [prev: (nil)] 0x57676b90: "/host/usr/lib/i386-linux-gnu/libXau.so.6.0.0" [next: 0x57676e90]
   [prev: 0x57676b90] 0x57676e90: "/lib/i386-linux-gnu/libc.so.6" [next: 0x57677160]
   [prev: 0x57676e90] 0x57677160: "/lib/i386-linux-gnu/ld-linux.so.2" [next: 0x57672540]
   ⋮
   [prev: 0x57683e60] 0x57684190: "/host/usr/lib/i386-linux-gnu/libGL.so.1.2.0" [next: (nil)])

(dl-handle DEFAULT // the vanilla namespace
   [prev: (nil)] 0xf778f920: "" [next: 0xf778fc10]
   [prev: 0xf778f920] 0xf778fc10: "linux-gate.so.1" [next: 0xf77658d8]
   ⋮
   [prev: 0xf7766668] 0xf7766920: "/lib/i386-linux-gnu/libc.so.6" [next: 0xf7766c08]
   ⋮
   [prev: 0xf7228978] 0xf7228c58: "/lib/i386-linux-gnu/libz.so.1" [next: (nil)])

As you can see, two copies of libc.

I'm not saying it's the right approach: For reasons outlined in this thread and 
the other one I mentioned I think one libc mapping across both namespaces is
the right way to go - but that's not how it currently works and it _does_ mostly
currently work.

It falls down if memory allocation/freeing occurs across the namespace boundary
(ie alloc on one side, free on the other), but the two libcs mostly can't even
see one another.