Forum OpenACS Q&A: OpenACS/.LRN on Apple's OS X Panther
Any objections to the following additions?
1. Assume OS X Panther
2. OS X developer tools as a requirement to the docs
3. Fink as an install tool so adding things like readline and imagemagick are easier.
Walter McGinnis pointed me towards using Darwinports to install OpenACS on OS X. I posted his instructions on my site and have since spent some time creating Portfiles to simplify the process.
Right now, I can do:
$ sudo port install postgresql +devel +server $ sudo port install openacsand I end up with an installation of OpenACS 5.0.4 at http://localhost:8000 under unix-user
service0. The OpenACS portfile ensures that all of its dependencies are installed (aolserver, its modules, tdom, postgresql, tclwebtest) and then downloads the OpenACS tarball. Once all the pieces are in place, it runs the cool OpenACS install.sh script.
It's not quite perfect yet because I'm having trouble debugging a process-kill/restart problem, so currently, I have to manually restart the process after my
install openacs command.
Installing in this way might be a nice way to try OpenACS out, but it's probably not a good idea for a production site, since it doesn't offer many configuration options, it ignores things like setting up CVS, and darwinports (currently) doesn't offer a way to upgrade a package. You have to uninstall the old version and then install the new version.
I've been reluctant to post about this because I haven't had time to work on it and it's still really rough (and probably incorrect in places!). The right thing to do would be to start submitting these Portfiles to the darwinports project, but frankly I've been lazy
I do think recommending daemontools would be useful, but it's currently not available in fink or darwinports, so it would be another manual step.
Configuring Postgres on OSX with --enable-thread-safety throws an error. Apparently this only affects thread safety of libpq when opening database connections, so if AOLserver opens the pooled database connections in the main thread it's not an issue for us...
checking pthread.h usability... yes checking pthread.h presence... yes checking for pthread.h... yes configure: error: Cannot enable threads on your platform. Please report your platform threading info to the PostgreSQL mailing lists so it can be added to the next release. Report all compile flags, link flags, functions, or libraries required for threading support. See the comment at the top of src/port/thread.c for more information.
Also, there was discussion on the PG mailing lists a while ago (around PG 7.2 / OSX 10.1) that PG wasn't able to shut down cleanly when OSX is shut down - http://archives.postgresql.org/pgsql-hackers/2002-04/msg01514.php. There's no mention of a fix in the Postgres release notes since then, but the problem looks to have been in OSX rather than PG so it may have gone away between 10.1 and 10.3...
Finally, stock PG doesn't correctly build shared libraries on OSX, so everything ends up statically linked. The Fink PG install patches this to work correctly, but the patches don't seem to have made it back to the main PG tree. (I know this isn't really a problem, but while I'm bitching)...
and the install guide -
- libpq and ECPG applications are now fully thread-safe
- While previous libpq releases already supported threads, this release improves thread safety by fixing some non-thread-safe code that was used during database connection startup. The configure option --enable-thread-safety must be used to enable this feature.
Since nspostgres gets it's Postgres-ness from libpq, there is a potential issue if libpq is not thread safe and 2 threads silmultaneously try to open connections to the database. I don't know in detail how nspostgres handles recycling database connections, and given that database connections are long-lived in AOLserver it's probably pretty hard to trigger any lossage through this if it's even possible at all, but still...
- Make the client libraries thread-safe. This allows concurrent threads in libpq and ECPG programs to safely control their private connection handles.