This pertains to another question I requested earlier today.

I built SVN 1.6.2 from source. Along the way, it's completely messed up my dev atmosphere.

Once I built SVN, Apache wasn't loading. It had been giving me this error:

Syntax error on line 117 of /private/etc/apache2/httpd.conf: Cannot load /usr/libexec
/apache2/ into server: dlopen(/usr/libexec/apache2/, 10): no
suitable image found.  Did find:\n\t/usr/libexec/apache2/ mach-o, but
wrong architecture

It seems that SVN over-authored that old and i'm unable to have it to construct as Body fat, and that i can't recover whatever was initially there.

I resolved this(temporarily?) by leaving comments the line which was loading the and also got Apache to begin at this time.

However, despite the fact that Apache is running I'm now getting this error when attempting to gain access to my dev sites:

Directory index forbidden by Options directive: /usr/share/tomcat6/webapps/ROOT/

I've Apache2 relaxing in front of Tomcat6. I access my local dev site while using internal title "http://localthesite". I've had virtual sites setup which have labored until this SVN debacle.

Tomcat is installed at /usr/local/apache-tomcat, and webapps is /usr/local/apache-tomcat/webapps.

Our production servers deploy tomcat to /usr/share/tomcat6, and so i have symlinks setup on my small system to duplicate this too. These point to the particular installation path. It has all been working fine too.

None in our designs for Apache2, Tomcat, or .htaccess have transformed. Over the past weekend, I carried out a "Repair Disk Permissions" around the system. It was before I came across the problem.

I've been reading through on all of this morning and the most typical response is that there's an Options -Indexes set. We've this inside a config file, however it was there before so when I took it off throughout testing, I still got exactly the same errors from Apache.

At this time, I am presuming I either totally borked the native Apache2 installation about this Mac, or that there's a permissions error somewhere that I am missing. The permissions error might be in the SVN installation, or from the repair process.

Does anybody have any idea what is the issue? I am totally blocked at this time and also have no clue where you can check next.


grep -n Options /etc/httpd/*

To obtain all lines where there's an Options directive. For those who have any line which has -Indexes inside it then that could be it. You could also need to look for files. (In /private/etc/httpd/users/* I believe..)

Another factor may be the permissions. (Which sounds much more likely here.) In my opinion Apache requires a+x on the folder to show a catalog of their contents. Try

ls -l /usr/share/tomcat6/webapps/

And search for

drwxr-xr-x  1 user  user  100 Jun 15 13:37 ROOT/

You will need to create it with

chmod a+x /usr/share/tomcat6/webapps/ROOT

I am unsure relating to this when i haven't had exactly the same problem myself. Hope it really works!

(Sidenote: This is probably not what you are searching for however i can highly recommend MacPorts -- it is a tool that enables you to definitely install software (like apache, svn, mysql etc.) instantly with dependencies resolved right into a sand pit, to ensure that your default Mac OS X is untouched. You are able to deactivate and activate software and therefore easily try different versions etc. Link:

This might be associated with the "Options directive" problem you are getting, the answer bit for the reason that first error is

Did find:\n\t/usr/libexec/apache2/ mach-o, but wrong architecture

I am getting an identical problem between Apache and SVN, however with another library. My memory's just a little fuzzy about this, however i think some time back Apple switched to 64 bit binaries for many stuff. Most libraries on Mac OS X is going to be either i386 or x86_64 architecture. You are able to discover the architecture using the 'file' command, for instance:

file /usr/libexec/apache2/

that might output Mach-O 64-bit dynamically linked shared library x86_64

Should you compare the architectures of the svn and httpd executables and also the mod_dav_svn wordpress plugin you will probably find a conflict.