thread-safe popen

2005-07-05 Thread Dipjyoti Saikia
Hi, I am working on an OS derived for BSD 4.1 . I am trying to backport a thread-safe version of popen() from BSD 4.10 . My plan is to create a file in libc_r/uhtread as uthread_popen.c which will contain the thread safe version of the code . The problem I am facing while building the

building something from CVS with GNU autotools

2005-07-05 Thread Marco Molteni
I pulled all my hair and lost my sanity. I searched mailing lists ang google, found a lot of people with my same problem but never a definitive solution. Problem is when trying to build on fbsd no matter which program out of CVS (ie: not a release) which uses GNU autotools. After patching

Re: thread-safe popen

2005-07-05 Thread Dan Nelson
In the last episode (Jul 05), Dipjyoti Saikia said: I am working on an OS derived for BSD 4.1 . I am trying to backport a thread-safe version of popen() from BSD 4.10 . popen should be threadsafe as of rev 1.17 (2003-01-03) of /usr/src/lib/libc/gen/popen.c . It was merged into the 4.* branch

Re: building something from CVS with GNU autotools

2005-07-05 Thread Giorgos Keramidas
On 2005-07-05 16:14, Marco Molteni [EMAIL PROTECTED] wrote: I pulled all my hair and lost my sanity. I searched mailing lists ang google, found a lot of people with my same problem but never a definitive solution. Problem is when trying to build on fbsd no matter which program out of CVS

Re: building something from CVS with GNU autotools

2005-07-05 Thread Alecs King
On Tue, Jul 05, 2005 at 04:14:45PM +0200, Marco Molteni wrote: I pulled all my hair and lost my sanity. I searched mailing lists ang google, found a lot of people with my same problem but never a definitive solution. Problem is when trying to build on fbsd no matter which program out of CVS

ProPolice symbols in libc or libssp ?

2005-07-05 Thread Jeremie Le Hen
Hi hackers, I'm still working on integrating the ProPolice patch in FreeBSD CURRENT. A small reminder : The ProPolice patch prevents from stack-based buffer overflows but setting a canary between character arrays and the return address stored in the stack. In addition,

linking libjava.so RPATH problem

2005-07-05 Thread Tom Schutter
I am having problems linking in the Java JVM libraries (libjava.so, libverify.so, libjvm.so) into my executable. With these options added to my gcc command: -L/usr/local/jdk1.4.2/jre/lib/i386 -ljava -lverify -L/usr/local/jdk1.4.2/jre/lib/i386/server -ljvm It links ok, but when I try to run it

Re: linking libjava.so RPATH problem

2005-07-05 Thread Daniel O'Connor
On Wed, 6 Jul 2005 07:25, Tom Schutter wrote: 1) Why is the RPATH in the executable being ignored? I think this is a feature, not a bug.. I forget the exact reason though - I am pretty sure this has been discussed on the lists when ELF came in though. 2) When I add the -rpath, I get two

Re: linking libjava.so RPATH problem

2005-07-05 Thread Vasil Dimov
On Tue, Jul 05, 2005 at 03:55:26PM -0600, Tom Schutter wrote: I am having problems linking in the Java JVM libraries (libjava.so, libverify.so, libjvm.so) into my executable. With these options added to my gcc command: -L/usr/local/jdk1.4.2/jre/lib/i386 -ljava -lverify