I compiled 1.06 package in this OS,kernel version is 2.4.18,gcc 3.2.2 glibc 3.2.2.
when i run the test programs, they aborted.
it seems shm_open could not create a shared memory segment.
have you test the package under this?
i would like to modify the package using native shmget and shmat system calls,but i'm not so sure.
could you provide a version?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Sorry, the system used to work with shmget and shmat, but has moved on to work with the POSIX commands for future portability. You could yourself modify a version back to work with the Sys V OS commands.
I think you have a different problem though because the kernel, glibc, and gcc for the versions your describe should support shm_open. Perhaps your system is just attempting to open a file link, like in /tmp, for shm_open and the directory does not have the correct rw permissions set. I would work carefully with the debugger and see what lines of code cause the problem on your system and if there are any associated system error messages.
Try changing the Makefile to compile with -DDEBUG flag to turn on all possible debug messages.
Marc
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I run map_with_string_index, get the following
----------------------------------------
Map with String index tests.
Creating Map, adding entries
../include/pooled_allocator.h:351: Pool() : constructor.
../include/shared_memory.h:879 shared<>::allocate() : alloc_key_ss.str().data()
: /home/tender/shm/shm_1
0xbfffea40Aborted
by the way, file /home/tender/shm/shm_1 exists,and mode is 777
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
What about glibc 2.3.2? Did you install that library?
Thanks for the offer of the Sys V version, but I have really decide to stick with the POSIX system calls. Linux is migrating toward them, and they will allow for better portability in the future, I think. At least that is one of the POSIX goals.
Marc
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Jus out of curiosity, what are you using the allocator for? Have you tried posting your slackware questions on http://www.slackware.org
??
That would seem to be the logical place. I am fairly certain that shm_open is probably included in the glibc version which come with the latest slackware installation disks.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
yes,i put the question in slackware.org yesterday.
and hopefully somebody would find me a way out.
i use this allocator in multiprocess server programing,to share data between them.you know,using STL saves your time than directly using shared memory yourself,though i did so in the past.
regards.
stephen
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I compiled 1.06 package in this OS,kernel version is 2.4.18,gcc 3.2.2 glibc 3.2.2.
when i run the test programs, they aborted.
it seems shm_open could not create a shared memory segment.
have you test the package under this?
i would like to modify the package using native shmget and shmat system calls,but i'm not so sure.
could you provide a version?
Sorry, the system used to work with shmget and shmat, but has moved on to work with the POSIX commands for future portability. You could yourself modify a version back to work with the Sys V OS commands.
I think you have a different problem though because the kernel, glibc, and gcc for the versions your describe should support shm_open. Perhaps your system is just attempting to open a file link, like in /tmp, for shm_open and the directory does not have the correct rw permissions set. I would work carefully with the debugger and see what lines of code cause the problem on your system and if there are any associated system error messages.
Try changing the Makefile to compile with -DDEBUG flag to turn on all possible debug messages.
Marc
I run map_with_string_index, get the following
----------------------------------------
Map with String index tests.
Creating Map, adding entries
../include/pooled_allocator.h:351: Pool() : constructor.
../include/shared_memory.h:879 shared<>::allocate() : alloc_key_ss.str().data()
: /home/tender/shm/shm_1
0xbfffea40Aborted
by the way, file /home/tender/shm/shm_1 exists,and mode is 777
I print the strerr(errno),it says :Function not implemented.
did i use the wrong lib or something?
It sounds to me like your system is hosed. When the slackware version was setup, did it come with glic 2.3.2 or did you install glibc later?
Marc
I installed gcc3.2.2 myself.
now i modified shared_memory.h to use sys v interfaces. do you want a copy?
thus you can see whether it's ok or not.
stephen
What about glibc 2.3.2? Did you install that library?
Thanks for the offer of the Sys V version, but I have really decide to stick with the POSIX system calls. Linux is migrating toward them, and they will allow for better portability in the future, I think. At least that is one of the POSIX goals.
Marc
could i find a available version of shm_open for slackware linux ？
I need it eagerly.
thanks a lot
I think maybe system does not support. could you please give me some advice to make it work?
I need it eagerly.
Jus out of curiosity, what are you using the allocator for? Have you tried posting your slackware questions on
http://www.slackware.org
??
That would seem to be the logical place. I am fairly certain that shm_open is probably included in the glibc version which come with the latest slackware installation disks.
yes,i put the question in slackware.org yesterday.
and hopefully somebody would find me a way out.
i use this allocator in multiprocess server programing,to share data between them.you know,using STL saves your time than directly using shared memory yourself,though i did so in the past.
regards.
stephen