Announcement

Collapse
No announcement yet.

svn running on apache setup issues

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

  • 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

  • #2
    You need to set the environment variable "LD_LIBRARY_PATH" to prefer the "/usr/local/opt/apr-util/libexec/lib" path instead of the system path. You should do this in as small of a context as is possible, e.g. by editing the startup/shutdown script that you use to start/restart/stop Apache. Get the current value and prefix in the path above. Be very careful with this environment variable. You should likely read up on it a bit before using it. For example [url]http://www.tldp.org/HOWTO/Program-Library-HOWTO/shared-libraries.html[/url] .

    Comment


    • #3
      what would be the command to set that path and also do you know the name of the startup/shutdown script. I am running off a MacBook Pro OSX Sierra with apache 2.4. I can attach my httpd file if need be. thank you

      Comment


      • #4
        I am new to mac so bare with me sorry

        Comment


        • #5
          whats the command and the startup/shutdown script used. I am using OSX Sierra on MAC.

          Comment


          • #6
            I mistakenly assumed you were running Linux. Should have noticed the "dylib"... Sorry.

            MacOS uses a totally different startup/shutdown mechanism. Read "/usr/sbin/apachectl" for more information. Basically, it's using "/bin/launchctl". Honestly if you've turned off "System Integrity Protection" (SIP, [url]http://apple.stackexchange.com/questions/193368/what-is-the-rootless-feature-in-el-capitan-really[/url]) then I'd just add the "export DYLD_LIBRARY_PATH=/usr/local/opt/apr-util/libexec/lib" to the "/usr/sbin/apachectl" script itself. If not, then I'm really not sure what the right thing is for you to do.

            I will second the concerns of others about using these environment variables. They are really bandaids - normally used for development. The proper fix would be to get an upgrade for your /usr/local/opt/apr-util/libexec/lib/libaprutil-1.0.dylib (put in the the right place). Which version of MacOS are you using?

            Comment


            • #7
              I am running version Mac OSX Sierra. I did take a look at /usr/sbin/apachectl and can edit in atom, but I do not where to put the file path of "export DYLD_LIBRARY_PATH=/usr/local/opt/apr-util/libexec/lib" at to stop it from defaulting to /usr/lib/libaprutil-1.0.dylib

              Comment


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

                Comment


                • #9
                  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.

                  Comment


                  • #10
                    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?

                    Comment


                    • #11
                      Yes, just like that.

                      Comment


                      • #12
                        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.

                        Comment


                        • #13
                          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.

                          Comment


                          • #14
                            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)

                            Comment


                            • #15
                              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.

                              Comment

                              Working...
                              X