When using emerge to emerge mod_ssl (which also emerges apache) it is broken out of box on both 1.1a for sparc64 and 1.4 beta tarballs. Everything compiles and installs fine, and running plain apache will work, but if you pass apache the option -DSSL to start up mod_ssl, apache starts to load then dies with no errors or output. It hangs when generating the DH keys. This was tested on mulitple new installs on seperate ultra10 workstations and by someone else in #gentoo-linux on an ultra1.
I forgot to mention that a straight vanilla download and hand compile of the latest openssl, mod_ssl and apache 1.3.26 works fine. Somewhere the ebuild is doing something that is making apache not happy with mod_ssl.
bummer, but interesting... it works fine out-of-the-box here on x86 as of today, 3:53PM EST starting from a 1.4 stage-1 -> apache + mod_ssl. this is with glibc-2.2.5-r6, gcc-3.2-r1, mod_ssl-2.8.10, openssl-0.9.6e and also db-4 (probably 99% people are using db-3 but ive been using it here s/db-3/db4/ fine for months...) im sorry i dont have any sparc hardware to test on, but from what i can tell, whatever it is is likely to be a small build issue or other. perhaps a small sparc patch... i cant think of anything else atm without more information.
Indeed it is only on sparc that this occurs. I have a vanilla x86 box here and it works on 1.2 as well as 1.4 there. However on any sparc it will not run. Im positive it is the way emerge is compiling one of the pieces of software (openssl, mod_ssl, or apache) because as I said, if you download the source and do it by hand with no changes it works just fine. I have an ultra10 you can test on if need be. Just email me.
i am experiencing this exact same problem on ppc-1.4. apache fine. apache+mod_php fine. but any combination with mod_ssl causes apache to die on load. -brady
i just recomplied openssl. and apache appears to be working. before i was using -O3 and it wasnt working. now im using -O2 and it appears to be working. hope this helps. -brady
i was getting strange errors and sporadic brokenness from mod_ssl. then i recompiled mod_ssl, and now its exhibiting the exact same behavior as before. -brady
same thing happening here, anyone got an idea yet? I'll try rebuilding with less optimizations & post results later (my U1 isn't that fast.. :) )
Just as info about CFLAGS. I tested the following packages with CFLAGS='-O2 -pipe' on sparc64 and the error was _NOT_ fixed. apache-1.3.27-r1.tbz2 mod_php-4.2.3.tbz2 mod_ssl-2.8.12.tbz2 openssl-0.9.6g.tbz2 Test was done long time ago but i think i post the infos here because every time someone brings this topic back to life, people start talking about CFLAGS and optimisation again.
apache2 also fails with SSL enabled. It doesn't crash though. Apache starts and binds the ports but doesn't answer to any requests. Theres also an error in the logfile if SSL is enabled: "[error] initialize MM 746a8 RMM 74770"
I retried today with less CFLAGS hacks on "dev-lib/mm" because apache2 writes the error "[error] initialize MM 746a8 RMM 74770" to it's logfiles. Now apache 1.3.27 also doesn't crash anymore but behaves like apache2 (it starts and listens but doesn't answer any request). This test shows 2 things. First that it's also not a CFLAGS thing on dev-lib/mm. The second and much more important thing is that it could be something with dev-lib/mm on linux/sparc. 1.2.1 hat the keyword added around the 6. Dec. It doesn't work (still) but it bahaves different. Before it crashed (segfault) and now it starts and runs but doesn't behave correct.
Problem doesn't seem to go away when apache and mod_ssl is compiled without "mm" support. So it's most likely not a "dev-lib/mm" issue.
dropping optimizations on all related packages (openssl, apache, mm, mod_ssl) doesn't help, changing the ssl session cache to not use semaphores doesn't help, changing the sslmutex doesn't help, excluding mm from apache and mod_ssl doesn't help and there is nothing enlightening in the strace of apache. We really need someone with very technical expertise to look at this, any volunteers?
try building without SHARED_CHAIN, see if that makes a difference. im guessing not, but who knows. remove it from the ./configure and try that. if fails, im out of idea as Method has tried my other ideas.
As as side note, apache-1.3.27-r3 and mod_ssl-2.8.14 work out of the box for me om a SparcStation 4. Still no luck on an UltraSparc machine however.
apache and mod_ssl work out of the box on an Ultra 1 using the default-sparc64-1.0 profile. I built up a 1.0 system in a chroot using the stage3-sparc64-1.1a.tbz2 and emerge -u system, then emerged apache and mod_ssl. So it would seem that gcc 3.x and/or glibc 2.3.x might have something to do with this.
Looking at this a little more. Tried building apache + mod_ssl outside of portage to make sure it wasn't somehow a Gentoo problem. No change. I'm going to try posting to the mod_ssl users mailing list and see what comes up.
This happens with apache2 as well. Submitted a bug to the Apache2 ppl about it. Wanted to submit a bug to the mod_ssl people for apache1, but their bug reporting mechanism is broken.
Created attachment 14943 [details] th3mp's mod_ssl notes These are the notes th3mp made about getting mod_ssl and apache 1.x to work on sparc64. If anyone wants to play around feel free as I will not have time for a week or so.
Created attachment 14944 [details] th3mp's mod_ssl notes These are the notes th3mp made about getting mod_ssl and apache 1.x to work on sparc64. If anyone wants to play around feel free as I will not have time for a week or so.
If anyone wants to follow the bug I've submitted with the apache2 people, it's available at http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21485.
If you add the line AcceptMutex fcntl to your /etc/apache/conf/apache.conf file near the top (w/DocumentRoot), it solves this problem.
So here's the scoop on what's happening here. It isn't mod_ssl that's causing the problem, it's having apache listen on more than one port. You can replicate it by adding an additional Listen port to your /etc/apache/conf/apache.conf while SSL is disabled. This effects apache 1.3.x as well as apache 2.0.x. Waiting to hear back from the apache folks to see if they have a suggested method of fixing this. In the mean time, we could fix this by adding an AcceptMutex line into the installed configs for sparc64s. Woodchip, how does that sound to you?
No problem with me. The configs are maintained in apache/files so if you want to stuff in a line if sparc64's somewhere in src_install that sounds like it'd work for ya.
Current portage ebuilds have now been adjusted to use AcceptMutex fcntl by default for sparcs. Everyone please test and provide feedback.
works fine here. apache-2.0.47 Linux sparcy 2.4.20-sparc-r8 #4 Thu Jun 19 00:08:44 CDT 2003 sparc64 sun4u TI UltraSparc IIe GNU/Linux
Marking as fixed as no one has reported problems with the modified ebuilds.