Announcement

Collapse
No announcement yet.

svn running on apache setup issues

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • zurekdj01
    started a topic svn running on apache setup issues

    svn running on apache setup issues

    httpd: Syntax error on line 153 of /private/etc/apache2/httpd.conf: Cannot load local/libexec/apache2/mod_dav_svn.so into server: dlopen(/usr/local/libexec/apache2/mod_dav_svn.so, 10): Library not loaded: /usr/local/opt/apr-util/libexec/lib/libaprutil-1.0.dylib\n Referenced from: /usr/local/libexec/apache2/mod_dav_svn.so\n Reason: Incompatible library version: mod_dav_svn.so requires version 6.0.0 or later, but libaprutil-1.0.dylib provides version 4.0.0


    currently this is the error I get when I restart apache server. I currently certain that when I installed apache is defaulted to a file path reading in /usr/lib/libaprutil-1.0.dylib which has a version of 4.0.0 as you can see from above. the file path listen above as /usr/local/opt/apr-util/libexec/lib/libaprutil-1.0.dylib has another file version of 6.4. That is the correct file to be read in when I restart apache. my question is how do I revert the read in path to /usr/local/opt/apr-util/libexec/lib/libaprutil-1.0.dylib\ not /usr/lib/libaprutil-1.0.dylib. Thank You

  • DougR
    replied
    Dates are unimportant and mis-leading. The critical part to shared runtime libraries is that the compile-time environment be identical. You cannot expect mix-N-match from different sources to work. It is extremely clear by the error messages that they do not match at all. Time to clear out Apache, libexec, etc. and load a new set that do match.

    Leave a comment:


  • zurekdj01
    replied
    As far as I see, the /usr/lib directory has the libaprutil created on oct 2016 and when I installed apache when I got my computer obviously on the date that I installed?

    Leave a comment:


  • DougR
    replied
    If you installed the "libexec" via brew then you must install Apache via the same source.

    Leave a comment:


  • zurekdj01
    replied
    I currently did not install apache through brew.

    Leave a comment:


  • zurekdj01
    replied
    should I reinstall Apache or ???

    Leave a comment:


  • zurekdj01
    replied
    idk what else to do here. The apache version is Server version: Apache/2.4.23 (Unix) and my co worker is not having the same issue.

    Leave a comment:


  • zurekdj01
    replied
    Server version: Apache/2.4.23 (Unix) Thats my version of apache that I am running. I had a co-worker setup a brand new macbook pro as well and he has had no isssues with setting up the same thing. idk what else to do.

    Leave a comment:


  • zurekdj01
    replied
    I had another co-worker setup a brand new MacBookPro doing the exact same thing and had no issue with it. my Apache version is Server version: Apache/2.4.23 (Unix)

    Leave a comment:


  • DougR
    replied
    Thank you for trying that. What it points out is that the Apache you are using is actually not compatible with the libexec library that you want it to load.

    Simply put, any shared-library-loadable image really needs to be compiled explicitly to match the executable that is going to load it. While it is possible for minor version changes to still be compatible (e.g. a "contract neutral bug fix release"), any changes that change the calling sequence or any functional contract thereof require at a minimum a recompilation (and at a maximum some actual programming). Note that the executables and the shared libraries can and do call back and forth between themselves at times so all contracts within the various API scopes need to be considered.

    In this case the Apache is operating under one "contract" and the shared library is operating under a different "contract" and that pretty much won't work.

    Not sure how you obtained that libexec but it simply won't run with that Apache.

    Leave a comment:


  • zurekdj01
    replied
    this is what I get next after editing the /usr/sbin/apachectl



    dyld: Symbol not found: _apr_ldap_get_option
    Referenced from: /usr/sbin/httpd
    Expected in: /usr/local/opt/apr-util/libexec/lib/libaprutil-1.0.dylib
    in /usr/sbin/httpd
    /usr/sbin/apachectl: line 93: 10727 Abort trap: 6 $HTTPD "$@"



    Last edited by zurekdj01; 02-13-2017, 02:47 PM.

    Leave a comment:


  • DougR
    replied
    Yes, just like that.

    Leave a comment:


  • zurekdj01
    replied
    LAUNCHCTL="/bin/launchctl"
    LAUNCHD_JOB="/System/Library/LaunchDaemons/org.apache.httpd.plist"
    export DYLD_LIBRARY_PATH=/usr/local/opt/apr-util/libexec/lib

    just like this?

    Leave a comment:


  • DougR
    replied
    The key concept is that environment variables are passed from parent process to child process. The parent process can decide not to deliver the EV to the child. The child can decide to eliminate the EV before doing anything else. But neither of those are the norm. Of course, "launchctl" could choose to remove it. I have no experience with it. However, just to test things out I would export the environment variable just after the assignment of the 2 "LAUNCH*" variables in lines 69/70. The rest of the script is only concerned with stopping, starting, restarting, etc. Apache so should not contaminate anything else.

    Leave a comment:


  • zurekdj01
    replied
    Is there by chance a diagram as to going about doing this process. I cant find anything close to what I am dealing with :(

    Leave a comment:

Working...
X