To phrase this most clearly: you cannot do exactly what you asked. Linux does not support sharing of global variables that are laid out by the linker. That memory will be in unsharable mapped-to-swap space.

A general recipe I can offer is this:

1. define a struct that lays out your data. No Pointers! Just offsets.
2. first process creates a file in /tmp, sets access rw as needed. Open, mmap with MAP_SHARED.
3. Subsequent processes also open, mmap with MAP_SHARED.
4. everybody uses the struct to find the pieces they reference, read, or write.
5. Look Out For Concurrency!

If you really only care about a parent and it s forked children, you can use an anonymous mapping and not bother with the file, and you can store the location of the mapping in a global (which can be read in the children).

If you only want to share the data with and among descendent processes (and not with arbitrary processes that are started up seperately, that just happen to link to the same shared library), then the easiest way to do this is have the library create a mapping with mmap() in a constructor function (that is called when the library is initially loaded in the parent process).

Pass the MAP_ANONYMOUS and MAP_SHARED flags to mmap - this will mean that child processes that inherit the mapping will have a mapping that is shared with the parent (and the other children). The library should then store data structures to be shared within that mmaped memory segment (just as if it was memory returned from malloc). Obviously you may need some kind of locking.

Constructor functions for libraries can be indicated using the gcc __constructor__ function attribute.

You don t need to worry about cleaning-up this kind of shared memory - when the last process with an anonymous mapping exits, the memory will be cleaned up.

How about creating a simple pipe in a known directory location, then get other processes to fopen the pipe for reading/writing a la fread/fwrite respectively, to share data...the tricky part is ensuring that the data is passed through the pipe in a manner not to cause corruption in this case. The above you mentioned using shared memory shm_ and mmap is tied to the process, when you fork code, that s no problem since the fork d code is part of the original process! Hope this helps.

Best regards, Tom.