You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@apr.apache.org by rb...@apache.org on 2002/03/20 20:45:02 UTC
cvs commit: apr/dso/unix dso.c
rbb 02/03/20 11:45:02
Modified: . CHANGES
dso/unix dso.c
Log:
Load libraries if they not MH_BUNDLE, but if they are not, it
just attempts to link them as shared libs. This is required to get
the JVM loaded through APR.
Submitted by: Pier Fumagalli <pi...@betaversion.org>
Reviewed by: Ryan Bloom
Revision Changes Path
1.243 +5 -0 apr/CHANGES
Index: CHANGES
===================================================================
RCS file: /home/cvs/apr/CHANGES,v
retrieving revision 1.242
retrieving revision 1.243
diff -u -r1.242 -r1.243
--- CHANGES 16 Mar 2002 03:54:00 -0000 1.242
+++ CHANGES 20 Mar 2002 19:45:02 -0000 1.243
@@ -1,5 +1,10 @@
Changes with APR b1
+ *) Load libraries if they not MH_BUNDLE, but if they are not, it
+ just attempts to link them as shared libs.
+ [Pier Fumagalli <pi...@betaversion.org>]
+
+
*) apr_atomic_dec now returns a zero value if the value of
the atomic is zero, non-zero otherwise [Ian Holsman]
1.49 +25 -11 apr/dso/unix/dso.c
Index: dso.c
===================================================================
RCS file: /home/cvs/apr/dso/unix/dso.c,v
retrieving revision 1.48
retrieving revision 1.49
diff -u -r1.48 -r1.49
--- dso.c 13 Mar 2002 20:39:09 -0000 1.48
+++ dso.c 20 Mar 2002 19:45:02 -0000 1.49
@@ -72,6 +72,10 @@
#include <string.h> /* for strerror() on HP-UX */
#endif
+#if defined(DSO_USE_DYLD)
+#define DYLD_LIBRARY_HANDLE (void *)-1
+#endif
+
APR_DECLARE(apr_status_t) apr_os_dso_handle_put(apr_dso_handle_t **aprdso,
apr_os_dso_handle_t osdso,
apr_pool_t *pool)
@@ -99,7 +103,9 @@
#if defined(DSO_USE_SHL)
shl_unload((shl_t)dso->handle);
#elif defined(DSO_USE_DYLD)
- NSUnLinkModule(dso->handle, FALSE);
+ if (dso->handle != DYLD_LIBRARY_HANDLE) {
+ NSUnLinkModule(dso->handle, FALSE);
+ }
#elif defined(DSO_USE_DLFCN)
if (dlclose(dso->handle) != 0)
return APR_EINIT;
@@ -119,18 +125,21 @@
NSObjectFileImage image;
NSModule os_handle = NULL;
char* err_msg = NULL;
- if (NSCreateObjectFileImageFromFile(path, &image) != NSObjectFileImageSuccess) {
- err_msg = "cannot create object file image";
- }
- else {
+ if (NSCreateObjectFileImageFromFile(path, &image) == NSObjectFileImageSuccess) {
#ifdef NSLINKMODULE_OPTION_PRIVATE
- os_handle = NSLinkModule(image, path,
- NSLINKMODULE_OPTION_PRIVATE |
- NSLINKMODULE_OPTION_RETURN_ON_ERROR);
+ os_handle = NSLinkModule(image, path,
+ NSLINKMODULE_OPTION_PRIVATE |
+ NSLINKMODULE_OPTION_RETURN_ON_ERROR);
#else
- os_handle = NSLinkModule(image, path, TRUE);
+ os_handle = NSLinkModule(image, path, TRUE);
#endif
- NSDestroyObjectFileImage(image);
+ NSDestroyObjectFileImage(image);
+ }
+ else if (NSAddLibrary(path) == TRUE) {
+ os_handle = (NSModule)DYLD_LIBRARY_HANDLE;
+ }
+ else {
+ err_msg = "cannot create object file image or add library";
}
#elif defined(DSO_USE_DLFCN)
@@ -208,7 +217,12 @@
char *symname2 = (char*)malloc(sizeof(char)*(strlen(symname)+2));
sprintf(symname2, "_%s", symname);
#ifdef NSLINKMODULE_OPTION_PRIVATE
- symbol = NSLookupSymbolInModule((NSModule)handle->handle, symname2);
+ if (handle->handle == DYLD_LIBRARY_HANDLE) {
+ symbol = NSLookupAndBindSymbol(symname2);
+ }
+ else {
+ symbol = NSLookupSymbolInModule((NSModule)handle->handle, symname2);
+ }
#else
symbol = NSLookupAndBindSymbol(symname2);
#endif
Re: cvs commit: apr/dso/unix dso.c
Posted by Aaron Bannert <aa...@clove.org>.
On Tue, Mar 26, 2002 at 12:29:46AM +0100, Jens-Uwe Mager wrote:
> I did have remarkable few problems with the AIX 4.3 pthread library
> (before they started the N to M user to kernel level scheduling thingy).
> Also the Solaris 8 one user level thread to one kernel LWP thread
> library in /usr/lib/lwp works remarkably well. The Solaris N to M user
> to kernel level thread library appears to complex to make it work well
> at all.
The rumor is that in Sol9 the 1:1 thread lib will be default.
-aaron
Re: cvs commit: apr/dso/unix dso.c
Posted by Jeff Trawick <tr...@attglobal.net>.
Jens-Uwe Mager <ju...@anubis.han.de> writes:
> On Mon, Mar 25, 2002 at 03:20:27PM -0800, Aaron Bannert wrote:
> > On Tue, Mar 26, 2002 at 12:04:07AM +0100, Jens-Uwe Mager wrote:
> > > Darwin is a BSD kernel on top of MACH. The current implementation maps
> > > POSIX threads to MACH kernel threads in a one to one implementation. The
> > > implementation is not without flaws either, as for example there are
> > > problems with cancellation, signal handling (I believe) and process
> > > shared mutexes.
> >
> > Awesome! That is good news -- what OS' thread lib doesn't have problems
> > with thread cancellation and signal handling? ;)
>
> I did have remarkable few problems with the AIX 4.3 pthread library
> (before they started the N to M user to kernel level scheduling thingy).
FYI... Apache sets an environment variable to use 1:1 user:kernel
threads. I was advised by AIX folks that unless you are CPU bound it
is best to override the default and use 1:1.
--
Jeff Trawick | trawick@attglobal.net
Born in Roswell... married an alien...
Re: cvs commit: apr/dso/unix dso.c
Posted by Jens-Uwe Mager <ju...@anubis.han.de>.
On Mon, Mar 25, 2002 at 03:20:27PM -0800, Aaron Bannert wrote:
> On Tue, Mar 26, 2002 at 12:04:07AM +0100, Jens-Uwe Mager wrote:
> > Darwin is a BSD kernel on top of MACH. The current implementation maps
> > POSIX threads to MACH kernel threads in a one to one implementation. The
> > implementation is not without flaws either, as for example there are
> > problems with cancellation, signal handling (I believe) and process
> > shared mutexes.
>
> Awesome! That is good news -- what OS' thread lib doesn't have problems
> with thread cancellation and signal handling? ;)
I did have remarkable few problems with the AIX 4.3 pthread library
(before they started the N to M user to kernel level scheduling thingy).
Also the Solaris 8 one user level thread to one kernel LWP thread
library in /usr/lib/lwp works remarkably well. The Solaris N to M user
to kernel level thread library appears to complex to make it work well
at all.
--
Jens-Uwe Mager <pgp-mailto:62CFDB25> <ja...@jabber.com>
Re: cvs commit: apr/dso/unix dso.c
Posted by Aaron Bannert <aa...@clove.org>.
On Tue, Mar 26, 2002 at 12:04:07AM +0100, Jens-Uwe Mager wrote:
> Darwin is a BSD kernel on top of MACH. The current implementation maps
> POSIX threads to MACH kernel threads in a one to one implementation. The
> implementation is not without flaws either, as for example there are
> problems with cancellation, signal handling (I believe) and process
> shared mutexes.
Awesome! That is good news -- what OS' thread lib doesn't have problems
with thread cancellation and signal handling? ;)
-a
Re: cvs commit: apr/dso/unix dso.c
Posted by Pier Fumagalli <pi...@betaversion.org>.
"Jens-Uwe Mager" <ju...@anubis.han.de> wrote:
>> Can't really tell from that. Anyone else know what threading library
>> Darwin uses?
>
> Darwin is a BSD kernel on top of MACH. The current implementation maps
> POSIX threads to MACH kernel threads in a one to one implementation. The
> implementation is not without flaws either, as for example there are
> problems with cancellation, signal handling (I believe) and process
> shared mutexes.
It seems to work all-right on my development box, I loaded Apache 2.0.32
with some 200/300 clients, and didn't observe any weirdness, but hey, I
wouldn't bet my salary on that :)
>>> On Darwin semget and semctl are there, but there is no SEM_UNDO, the
>>> pthread_mutexattr_setpshared (of course) is not there, but I'm wondering if
>>> there's another way to handle things without using files, which just is a
>>> kick in the **** :)
>>
>> I dunno, don't have a darwin box. :)
>
> There is no real cross process locking that works without a system call
> in the non-congested case in Darwin. I did resort to using the spin
> locks from the historic MACH cthreads implementation which is still used
> in a lot of code from the standard libraries (both cthreads and pthreads
> map to the underlying MACH kernel threads one to one). Unfortunately
> they do not ship their cthread.h file they use to build the system, but
> I grabbed it from the Darwin CVS.
Wicked... Even less supported than sem_... :( One day when they'll be able
to send me my password for the CVS thinghie, I'll might be able to give it a
look :(
Pier
Re: cvs commit: apr/dso/unix dso.c
Posted by Jens-Uwe Mager <ju...@anubis.han.de>.
On Mon, Mar 25, 2002 at 02:53:48PM -0800, Aaron Bannert wrote:
> On Mon, Mar 25, 2002 at 10:32:03PM +0000, Pier Fumagalli wrote:
> > > Awesome! Does OS X have its own pthread implementation (not based on
> > > FreeBSD's)?
> >
> > Apparently, since it works allright... This is all I can figure out though:
> >
> > [...]
> > checking for pthread.h... yes
> > checking whether pthread_getspecific takes two arguments... no
> > checking whether pthread_attr_getdetachstate takes one argument... no
> > checking for pthread_key_delete... yes
> > checking for pthread_rwlock_init... no
> > APR will use threads
> > [...]
>
> Can't really tell from that. Anyone else know what threading library
> Darwin uses?
Darwin is a BSD kernel on top of MACH. The current implementation maps
POSIX threads to MACH kernel threads in a one to one implementation. The
implementation is not without flaws either, as for example there are
problems with cancellation, signal handling (I believe) and process
shared mutexes.
> > > We use file-based
> > > locks by default because they are the most portable, but if we had
> > > reason to believe that another method was better then we could
> > > change the default on a platform-by-platform basis in autoconf.
> > > APR locks support a bunch of different interprocess lock types.
> >
> > Noticed that :) All I can tell you is that under Darwin the apr_lock
> > implementation method is "SVR4-style fcntl()". Check this out:
>
> Just an FYI: apr_lock is going away and should not be used. apr_proc_mutex
> is a split-out of the interprocess parts of apr_lock.
>
> > checking for semget... yes
> > checking for semctl... yes
> > checking for flock... yes
> > checking for /dev/zero... (cached) yes
> > checking for union semun in sys/sem.h... no
> > checking for LOCK_EX in sys/file.h... yes
> > checking for F_SETLK in fcntl.h... yes
> > checking for SEM_UNDO in sys/sem.h... no
> > checking for CODESET in langinfo.h... no
> > checking for POLLIN in poll.h sys/poll.h... no
> > checking for PTHREAD_PROCESS_SHARED in pthread.h... no
> > checking for pthread_mutexattr_setpshared... no
> > decision on apr_lock implementation method... SVR4-style fcntl()
> > checking if interprocess lock affects threads... no
> >
> > On Darwin semget and semctl are there, but there is no SEM_UNDO, the
> > pthread_mutexattr_setpshared (of course) is not there, but I'm wondering if
> > there's another way to handle things without using files, which just is a
> > kick in the **** :)
>
> I dunno, don't have a darwin box. :)
There is no real cross process locking that works without a system call
in the non-congested case in Darwin. I did resort to using the spin
locks from the historic MACH cthreads implementation which is still used
in a lot of code from the standard libraries (both cthreads and pthreads
map to the underlying MACH kernel threads one to one). Unfortunately
they do not ship their cthread.h file they use to build the system, but
I grabbed it from the Darwin CVS.
--
Jens-Uwe Mager <pgp-mailto:62CFDB25> <ja...@jabber.com>
Re: cvs commit: apr/dso/unix dso.c
Posted by Pier Fumagalli <pi...@betaversion.org>.
"Aaron Bannert" <aa...@clove.org> wrote:
> Can't really tell from that. Anyone else know what threading library
> Darwin uses?
It _looks_ (I'm not implying it does), that it's using a some sort of
OSF/MkLinux thing... In pthread.h, this is what I found:
/*
* Copyright 1996 1995 by Open Software Foundation, Inc. 1997 1996 [...]
[...]
* MkLinux
*/
[...]
Weirrrrrdddddd....
> Just an FYI: apr_lock is going away and should not be used. apr_proc_mutex
> is a split-out of the interprocess parts of apr_lock.
I know (thanks David for trying to make me understand what was going on! :)
The story doesn't change...
>> On Darwin semget and semctl are there, but there is no SEM_UNDO, the
>> pthread_mutexattr_setpshared (of course) is not there, but I'm wondering if
>> there's another way to handle things without using files, which just is a
>> kick in the **** :)
>
> I dunno, don't have a darwin box. :)
You're more than welcome to borrow an account on one of my OS/X 10.1.3
boxes... :)
>> This is also because (apart from speed) most of the file paths in HTTPD are
>> "hard coded" (check this as an example):
>>
>> # grep 'logs/.*lock' `find $HTTPD2_SRC/server/mpm -type f`
>> ../netware/mpm_default.h: #define DEFAULT_LOCKFILE "logs/accept.lock"
>> ../perchild/mpm_default.h:#define DEFAULT_LOCKFILE "logs/accept.lock"
>> ../prefork/mpm_default.h:#define DEFAULT_LOCKFILE "logs/accept.lock"
>> ../worker/mpm_default.h:#define DEFAULT_LOCKFILE "logs/accept.lock"
>>
>> DOH! :) I don't have the "logs" directory in my HTTPD 2.0 install (took me
>> ages to figure that out!)
>
> Yeah, that's definately broken. Those should be defined in autoconf
> to at least be relative to the $runtimedir.
I know, and "complained" politely already on dev@httpd :) Someone was
supposed to come up with a patch :)
> The question is if APR can support semaphores to be used as mutexes w/o
> SEM_UNDO, and if it can will it be safe?
Yessir :) Or use the set of sem_... functions (but I believe Jim already
replied to that)...
> BTW, what does `grep SERIALIZE include/apr.h` produce on your darwin box?
Usual stuff... Lot's a 0s and some 1s (but all in the wrong places! :)
#define APR_USE_FLOCK_SERIALIZE 0
#define APR_USE_SYSVSEM_SERIALIZE 0
#define APR_USE_FCNTL_SERIALIZE 1
#define APR_USE_PROC_PTHREAD_SERIALIZE 0
#define APR_USE_PTHREAD_SERIALIZE 1
#define APR_HAS_FLOCK_SERIALIZE 1
#define APR_HAS_SYSVSEM_SERIALIZE 0
#define APR_HAS_FCNTL_SERIALIZE 1
#define APR_HAS_PROC_PTHREAD_SERIALIZE 0
#define APR_HAS_RWLOCK_SERIALIZE 0
Pier
Re: cvs commit: apr/dso/unix dso.c
Posted by Aaron Bannert <aa...@clove.org>.
On Mon, Mar 25, 2002 at 10:32:03PM +0000, Pier Fumagalli wrote:
> > Awesome! Does OS X have its own pthread implementation (not based on
> > FreeBSD's)?
>
> Apparently, since it works allright... This is all I can figure out though:
>
> [...]
> checking for pthread.h... yes
> checking whether pthread_getspecific takes two arguments... no
> checking whether pthread_attr_getdetachstate takes one argument... no
> checking for pthread_key_delete... yes
> checking for pthread_rwlock_init... no
> APR will use threads
> [...]
Can't really tell from that. Anyone else know what threading library
Darwin uses?
> > We use file-based
> > locks by default because they are the most portable, but if we had
> > reason to believe that another method was better then we could
> > change the default on a platform-by-platform basis in autoconf.
> > APR locks support a bunch of different interprocess lock types.
>
> Noticed that :) All I can tell you is that under Darwin the apr_lock
> implementation method is "SVR4-style fcntl()". Check this out:
Just an FYI: apr_lock is going away and should not be used. apr_proc_mutex
is a split-out of the interprocess parts of apr_lock.
> checking for semget... yes
> checking for semctl... yes
> checking for flock... yes
> checking for /dev/zero... (cached) yes
> checking for union semun in sys/sem.h... no
> checking for LOCK_EX in sys/file.h... yes
> checking for F_SETLK in fcntl.h... yes
> checking for SEM_UNDO in sys/sem.h... no
> checking for CODESET in langinfo.h... no
> checking for POLLIN in poll.h sys/poll.h... no
> checking for PTHREAD_PROCESS_SHARED in pthread.h... no
> checking for pthread_mutexattr_setpshared... no
> decision on apr_lock implementation method... SVR4-style fcntl()
> checking if interprocess lock affects threads... no
>
> On Darwin semget and semctl are there, but there is no SEM_UNDO, the
> pthread_mutexattr_setpshared (of course) is not there, but I'm wondering if
> there's another way to handle things without using files, which just is a
> kick in the **** :)
I dunno, don't have a darwin box. :)
> This is also because (apart from speed) most of the file paths in HTTPD are
> "hard coded" (check this as an example):
>
> # grep 'logs/.*lock' `find $HTTPD2_SRC/server/mpm -type f`
> ../netware/mpm_default.h: #define DEFAULT_LOCKFILE "logs/accept.lock"
> ../perchild/mpm_default.h:#define DEFAULT_LOCKFILE "logs/accept.lock"
> ../prefork/mpm_default.h:#define DEFAULT_LOCKFILE "logs/accept.lock"
> ../worker/mpm_default.h:#define DEFAULT_LOCKFILE "logs/accept.lock"
>
> DOH! :) I don't have the "logs" directory in my HTTPD 2.0 install (took me
> ages to figure that out!)
Yeah, that's definately broken. Those should be defined in autoconf
to at least be relative to the $runtimedir.
> > (IME, pthread-based locks tend to be the fastest, but not many platforms
> > support that.)
>
> IME -> In My Experience ??? :) how about semaphores against file locks?
The question is if APR can support semaphores to be used as mutexes w/o
SEM_UNDO, and if it can will it be safe?
BTW, what does `grep SERIALIZE include/apr.h` produce on your darwin box?
-aaron
Re: cvs commit: apr/dso/unix dso.c
Posted by Pier Fumagalli <pi...@betaversion.org>.
"Aaron Bannert" <aa...@clove.org> wrote:
> On Mon, Mar 25, 2002 at 08:29:21PM +0000, Pier Fumagalli wrote:
>> It works, it works... I still didn't try it in production, but 2.0.32 was
>> pretty stable (never got segfaults even with worker), on 10.1.3.
>
> Awesome! Does OS X have its own pthread implementation (not based on
> FreeBSD's)?
Apparently, since it works allright... This is all I can figure out though:
[...]
checking for pthread.h... yes
checking whether pthread_getspecific takes two arguments... no
checking whether pthread_attr_getdetachstate takes one argument... no
checking for pthread_key_delete... yes
checking for pthread_rwlock_init... no
APR will use threads
[...]
>> The only "PITA" is locking, we'd really have to find an inter-process
>> locking mechanism != from files under OS/X (file locking is _so_ slow!)
>
> What are you using your interprocess lock for?
Whatever APR provides me :)
> We use file-based
> locks by default because they are the most portable, but if we had
> reason to believe that another method was better then we could
> change the default on a platform-by-platform basis in autoconf.
> APR locks support a bunch of different interprocess lock types.
Noticed that :) All I can tell you is that under Darwin the apr_lock
implementation method is "SVR4-style fcntl()". Check this out:
checking for semget... yes
checking for semctl... yes
checking for flock... yes
checking for /dev/zero... (cached) yes
checking for union semun in sys/sem.h... no
checking for LOCK_EX in sys/file.h... yes
checking for F_SETLK in fcntl.h... yes
checking for SEM_UNDO in sys/sem.h... no
checking for CODESET in langinfo.h... no
checking for POLLIN in poll.h sys/poll.h... no
checking for PTHREAD_PROCESS_SHARED in pthread.h... no
checking for pthread_mutexattr_setpshared... no
decision on apr_lock implementation method... SVR4-style fcntl()
checking if interprocess lock affects threads... no
On Darwin semget and semctl are there, but there is no SEM_UNDO, the
pthread_mutexattr_setpshared (of course) is not there, but I'm wondering if
there's another way to handle things without using files, which just is a
kick in the **** :)
This is also because (apart from speed) most of the file paths in HTTPD are
"hard coded" (check this as an example):
# grep 'logs/.*lock' `find $HTTPD2_SRC/server/mpm -type f`
../netware/mpm_default.h: #define DEFAULT_LOCKFILE "logs/accept.lock"
../perchild/mpm_default.h:#define DEFAULT_LOCKFILE "logs/accept.lock"
../prefork/mpm_default.h:#define DEFAULT_LOCKFILE "logs/accept.lock"
../worker/mpm_default.h:#define DEFAULT_LOCKFILE "logs/accept.lock"
DOH! :) I don't have the "logs" directory in my HTTPD 2.0 install (took me
ages to figure that out!)
> (IME, pthread-based locks tend to be the fastest, but not many platforms
> support that.)
IME -> In My Experience ??? :) how about semaphores against file locks?
Pier
Re: cvs commit: apr/dso/unix dso.c
Posted by Aaron Bannert <aa...@clove.org>.
On Mon, Mar 25, 2002 at 08:29:21PM +0000, Pier Fumagalli wrote:
> It works, it works... I still didn't try it in production, but 2.0.32 was
> pretty stable (never got segfaults even with worker), on 10.1.3.
Awesome! Does OS X have its own pthread implementation (not based on
FreeBSD's)?
> The only "PITA" is locking, we'd really have to find an inter-process
> locking mechanism != from files under OS/X (file locking is _so_ slow!)
What are you using your interprocess lock for? We use file-based
locks by default because they are the most portable, but if we had
reason to believe that another method was better then we could
change the default on a platform-by-platform basis in autoconf.
APR locks support a bunch of different interprocess lock types.
(IME, pthread-based locks tend to be the fastest, but not many platforms
support that.)
-aaron
Re: cvs commit: apr/dso/unix dso.c
Posted by Pier Fumagalli <pi...@betaversion.org>.
"Justin Erenkrantz" <je...@apache.org> wrote:
> Heh. My TiBook is on its way from Taiwan via FedEx.
That's _AWESOME_... Let me know when and I'll personally greet you into the
family :) (BTW, am I the only lucky person having a laptop with the
production date _same_ as his birthday??? :)
> So, I'm going to be making sure our stuff works on OS X. =)
It works, it works... I still didn't try it in production, but 2.0.32 was
pretty stable (never got segfaults even with worker), on 10.1.3.
The only "PITA" is locking, we'd really have to find an inter-process
locking mechanism != from files under OS/X (file locking is _so_ slow!)
> I believe there were some outstanding issues with the metadata on the
> filesystem. I'll probably be taking a look at that soonish then.
???? I have NO whatsoever clue on what you're talking about...
> I know I'm not the only committer with an Apple laptop (hi, Jim and
> Roy!).
I vote to get me commit access, so that when I get it, I can _really_ start
not doing ANYTHING! (like on Tomcat, you see! :)
Pier
Re: cvs commit: apr/dso/unix dso.c
Posted by Justin Erenkrantz <je...@apache.org>.
On Fri, Mar 22, 2002 at 08:24:18AM -0500, Jeff Trawick wrote:
> But if you folks with Mac OS X would stop committing your patches,
> just maybe Apple would get frustrated with lack of proper support and
> make some iBooks available for would-be developers. Maybe there is an
> iBook with a cracked case waiting for me somewhere. Or an iMac that
> came out puke green by mistake. (No, ssh to moof is not the same :) )
Heh. My TiBook is on its way from Taiwan via FedEx. So, I'm going
to be making sure our stuff works on OS X. =) I believe there
were some outstanding issues with the metadata on the filesystem.
I'll probably be taking a look at that soonish then.
I know I'm not the only committer with an Apple laptop (hi, Jim and
Roy!). -- justin
RE: cvs commit: apr/dso/unix dso.c
Posted by Ryan Bloom <rb...@covalent.net>.
> > "rbb@apache.org" <rb...@apache.org> wrote:
> >
> > > rbb 02/03/20 11:45:02
> > >
> > > + *) Load libraries if they not MH_BUNDLE, but if they are not,
it
> > > + just attempts to link them as shared libs.
> > > + [Pier Fumagalli <pi...@betaversion.org>]
> >
> > F*** YEAH! :) First patch into core APR...
>
> It is nice to see somebody so excited!
>
> But if you folks with Mac OS X would stop committing your patches,
> just maybe Apple would get frustrated with lack of proper support and
> make some iBooks available for would-be developers. Maybe there is an
> iBook with a cracked case waiting for me somewhere. Or an iMac that
> came out puke green by mistake. (No, ssh to moof is not the same :) )
I have to agree. I'll take any iBook, I'm not picky at all, as long as
it'll run OS X.
Ryan
Re: cvs commit: apr/dso/unix dso.c
Posted by Jeff Trawick <tr...@attglobal.net>.
Pier Fumagalli <pi...@betaversion.org> writes:
> "rbb@apache.org" <rb...@apache.org> wrote:
>
> > rbb 02/03/20 11:45:02
> >
> > + *) Load libraries if they not MH_BUNDLE, but if they are not, it
> > + just attempts to link them as shared libs.
> > + [Pier Fumagalli <pi...@betaversion.org>]
>
> F*** YEAH! :) First patch into core APR...
It is nice to see somebody so excited!
But if you folks with Mac OS X would stop committing your patches,
just maybe Apple would get frustrated with lack of proper support and
make some iBooks available for would-be developers. Maybe there is an
iBook with a cracked case waiting for me somewhere. Or an iMac that
came out puke green by mistake. (No, ssh to moof is not the same :) )
--
Jeff Trawick | trawick@attglobal.net
Born in Roswell... married an alien...
Re: cvs commit: apr/dso/unix dso.c
Posted by Pier Fumagalli <pi...@betaversion.org>.
"Ryan Bloom" <rb...@covalent.net> wrote:
>>
>>> rbb 02/03/20 11:45:02
>>>
>>> + *) Load libraries if they not MH_BUNDLE, but if they are not, it
>>> + just attempts to link them as shared libs.
>>> + [Pier Fumagalli <pi...@betaversion.org>]
>>
>> F*** YEAH! :) First patch into core APR... (now that piece of code is
> the
>> one which will blow the whole server up, but you already know that,
> don't
>> you?)
>>
>> Cheer Ryan :)
>
> Just test it Pier! I don't have access to OSX, so I couldn't. (I know
> about moof, but I forgot about it last night when I committed this.)
It's in "production" on bluebox.betaversion.org since quite some time now,
and that's the first (and only) patch I have to apply everytime I check out
APR on my development box... It has been tested, both with and without
MH_BUNDLE libraries, and both load fine...
Of course you can't unload non MH_BUNDLE libs (that's an OS "feature"), but
when you try to reload them it doesn't complain even if they weren't
unloaded...
Pier
RE: cvs commit: apr/dso/unix dso.c
Posted by Ryan Bloom <rb...@covalent.net>.
>
> > rbb 02/03/20 11:45:02
> >
> > + *) Load libraries if they not MH_BUNDLE, but if they are not, it
> > + just attempts to link them as shared libs.
> > + [Pier Fumagalli <pi...@betaversion.org>]
>
> F*** YEAH! :) First patch into core APR... (now that piece of code is
the
> one which will blow the whole server up, but you already know that,
don't
> you?)
>
> Cheer Ryan :)
Just test it Pier! I don't have access to OSX, so I couldn't. (I know
about moof, but I forgot about it last night when I committed this.)
Ryan
Re: cvs commit: apr/dso/unix dso.c
Posted by Pier Fumagalli <pi...@betaversion.org>.
"rbb@apache.org" <rb...@apache.org> wrote:
> rbb 02/03/20 11:45:02
>
> + *) Load libraries if they not MH_BUNDLE, but if they are not, it
> + just attempts to link them as shared libs.
> + [Pier Fumagalli <pi...@betaversion.org>]
F*** YEAH! :) First patch into core APR... (now that piece of code is the
one which will blow the whole server up, but you already know that, don't
you?)
Cheer Ryan :)
Pier (happy happy happy!)