Re: Regarding install and running svn1.9.2 for svnserve and http access in browser
Hi Ryan & Team, Thank for your inputs and now I have installed configured but compiled the wrong svn modules and need your inputs on new architecture dependency error. I am writing this email after googling and some research and with my finding in my install and configure in the test and prod environment. I have installed and configured Apache and compiled svn modules (mod_dav_svn and mod_authnz_svn) and loaded in Apache server. But having issues in Architecture compatibility issues for which I would like to know the compile options to generate svn modules. The production environment has the *Apache 2.2.17 *installed and instance created. It’s has Apache/2.2.17 (Unix), 32-bit, Server MPM as Prefork. The detailed version output is listed below under title *Apache 2.2.17 Prod. [Note: this is last release our production server is using for most of our applications, it’s the last version used in the production server]* I did compiled svn modules in another server since I do not want make the prod env dirty and to test in the lower environment. Then compiled svn modules (svn_mod_dav and svn_mod_authnz) separately in another server for Subversion 1.9.2 using Apache 2.4.18 which is 64 bit. Then re-started my apache instance which shows the below error. Initially, to compile apache svn modules I used Apache 2.2.17 and used *–apxs option and passed 2.2.17 version of apxs file path*. But subversion 1.9.2 configure script shows error like “*Apache version is too old*” and did not proceed. I don’t have the error output now. So installed Apache latest 2.4.18 which is stable version and compiled subversion 1.9.2 svn modules using option *--with-apache-libexecdir[=PATH] *and generated svn modules. While installing and compiling in test environment, I was not aware that I have to check/verify the Architecture dependency for Apache and Subversion. During that time I was using x86_64 bit downloaded version of Apache 2.4.18 and Subversion 1.9.2. *From the error it clearly says that I am using the 32-bit Apache and loading the mod_dav_svn module which is compiled using 64-bit Apache and Subversion.* *-bash-4.2$ ./instancectl restart* httpd: Syntax error on line 68 of /local/appweb/apache/instances/us1salx00603.80/local.conf: Syntax error on line 6 of /local/appweb/apache/instances/us1salx00603.80/logs/httpd.extras: Syntax error on line 7 of /local/appweb/apache/instances/us1salx00603.80/appconf/02-SVN-modules.conf: Cannot load /local/appweb/apache/installs/2.2.17/modules/mod_dav_svn.so into server: /local/appweb/apache/installs/2.2.17/modules/mod_dav_svn.so: wrong ELF class: ELFCLASS64 us1salx00603.80 graceful: failed - error 1 To resolve the above error and load svn modules, I need to compile the 32-bit svn modules. For this I need the 32 bit supported Apache and Subversion. mod_dav_svn modules using 32-bit Apache and 32-bit Subversion. But what I thought during choosing the package for download is based on Linux Architecture. I was under impression that Redhat Linux has only x86_64 bit and I have to use 64 bit supported files for install. So, now I have 2 options left to make http work in the production server. I have Redhat 7 server in the production. 1.Compile SVN modules using 32 bit to support my prod Apache 2.2.17/32-bit version. I need the correct version and architecture package for Subversion 1.9.2 and Apache 2.2.17. Since svn 1.9.2 configure script not taking the 2.2.17 Apache version, I believe I need to use the 2.4.18 apache 32 bit version. *Please correct me if I am wrong. Do I need to have both Apache and subversion as 32 bit or just Apache alone as 32 bit version. I doubt because compiling svn1.9 needs the apr/apr-util and with-apxs options which uses the apache modules. The mod_dav_svn.so is generated from the svn compilation and it uses the Apache modules.* 2.If at all my current Apache version 2.2.17 is not supported by Subversion 1.9.2 then I have to install Apache 2.4.18 64-bit which is already working. I read the INSTALL file inside the subversion 1.9.2.tar.bz2 file which say Apache 2.2.X is required. So believing it is not right. I don’t know why it throws the error for me. So, would like to know whether 2.2.17 is supported by Subversion 1.9.2 for http access and ldap. *Or I have go with Apache 2.4.18 version.* I am following the below URL for downloading and installing the packages. http://www.linuxfromscratch.org/blfs/view/svn/general/subversion.html So, I have few other questions which you would be aware of and I am asking the right community. 1.First question, In the below svn URL only one package is available and importantly no separate package like 32 or 64 bit mentioned for Linux platform. If my understanding is correct and since Apache is loading the modules and not subversion only apache has to be installed 32 bit and use apxs point to 32 bit apxs tool in the subversion. [ URL: https://subversion.apache.org/download.cgi#recommended-release] 2
Missing document
We're planning to do a dump and reload in an 1.9.3 upgrade we're planning to deploy on an 1.8.x server. We want to take advantage of all the repository improvements. However, I've just noticed that the related link at http://subversion.apache.org/docs/release-notes/1.9.html is missing. That is, http://svnbook.red-bean.com/en/1.9/svn.reposadmin.maint.html is missing as you can verify. Yours, Ricardo
Re: Bug report: svnversion crashes during Subversion build/install
On 2016Jan 7,, at 17:32, Ryan Schmidt wrote: > > During the build of Subversion 1.9.3, it calls the just-built svnversion > program. On OS X at least, this crashes because the just-built Subversion > libraries have not been installed yet so they are not in their expected > place. The crash causes OS X to create a crash log file, which I've attached, > but the relevant bit is: > > > Dyld Error Message: > Library not loaded: /opt/local/lib/libsvn_wc-1.0.dylib > Referenced from: /opt/local/var/macports/*/svnversion > Reason: image not found > > > I do set DESTDIR; that may be necessary to reproduce the problem. > > A solution on OS X is for the build system to set DYLD_LIBRARY_PATH to the > directory where the libraries can be found in the build directory, anytime > you want to run a just-built program that links with just-built libraries. I > imagine the problem would affect other unix operating systems as well, and > for them the solution may be to set LD_LIBRARY_PATH, but I am not familiar > with non-OS X unix systems. We have been seeing this problem a lot with FOSS on El Crapitan, caused by the new System Integrity Protection [SIP]. Unfortunately, the engineers who came up with this feature must not have used any software that wants to run tests prior to installation. Anyway, setting DYLD_LIBRARY_PATH [or any DYLD_*] won’t help: SIP makes sure that all subshells, scripts, etc get a bare environment specifically to prevent exactly what you are trying to do. As a user, the fix is to disable SIP before compiling. For the project, the short-term fix is probably going to be skipping the test on OS 10.11. Sent from David-Lowes-Mac-mini One may tolerate a world of demons for the sake of an angel.
Re: Bug report: svnversion crashes during Subversion build/install
Hi, On Fri, Jan 08, 2016 at 11:44:49AM -0800, David Lowe wrote: > On 2016Jan 7,, at 17:32, Ryan Schmidt wrote: > > > > During the build of Subversion 1.9.3, it calls the just-built svnversion > > program. On OS X at least, this crashes because the just-built Subversion > > libraries have not been installed yet so they are not in their expected > > place. The crash causes OS X to create a crash log file, which I've > > attached, but the relevant bit is: > > > > > > Dyld Error Message: > > Library not loaded: /opt/local/lib/libsvn_wc-1.0.dylib > > Referenced from: /opt/local/var/macports/*/svnversion > > Reason: image not found > > > > > > I do set DESTDIR; that may be necessary to reproduce the problem. > > > > A solution on OS X is for the build system to set DYLD_LIBRARY_PATH to the > > directory where the libraries can be found in the build directory, anytime > > you want to run a just-built program that links with just-built libraries. > > I imagine the problem would affect other unix operating systems as well, > > and for them the solution may be to set LD_LIBRARY_PATH, but I am not > > familiar with non-OS X unix systems. > > We have been seeing this problem a lot with FOSS on El Crapitan, caused > by the new System Integrity Protection [SIP]. Unfortunately, the engineers > who came up with this feature must not have used any software that wants to > run tests prior to installation. Hmm, wouldn't that perhaps happen to be a (albeit possibly not so?) clever way to force people to produce fully prefix-relocatable binaries, by ways of generic rpath etc. mechanisms? (via generic Linux $ORIGIN markers etc., see e.g. https://cmake.org/Wiki/CMake_RPATH_handling#CMake_and_the_RPATH ) I.e., a special way of saying "your build distillery is B0RKEN, fix it"? I've been going through the trouble of making my poor (currently unsupportable :() proprietary app fully supportive of relocation (for purposes of rpm relocation, shar archive, etc.) some 3 years ago, that's why this thought came up rather naturally. HTH, Andreas Mohr
