Problems getting DSO mod_perl2 to install into apache2

[Steve Post]

Trying to make Dynamic Shared Object (DSO) of mod_perl. .......for a few days......with apache2.

rp4440, HPUX 11.23, Apache2.2.11, mod_perl2.0.4
perl5.8.1 compiled to 32bit,gcc version 4.0.2, gmake


tar xvf mod_perl-2.0.4.tar
cd mod_perl-2.0.4

try1. I run perl ./Makefile.PL
apxs is at blahblah/apache_2.2.11_pl/bin/apxs
this works but complains about +Z

gmake fails immediately.

try2.
Shared libraries in hpux11.23 PA-RISC end in .sl instead of .so.
So maybe I can modify the Makefile's to use .sl?

I run perl ./Makefile.PL
apxs is at blahblah/apache_2.2.11_pl/bin/apxs
this works but complains about +Z

find . -name Makefile > goofyfile
vi goofyfile
Using this file, I run sed 's/\.sl/\.so/g' on all Makefiles.
This changes all spots that make .so files into .sl files.
But I am making the change blind because I can't see in the makefiles. (vi says "line too long).

gmake WORKS ....sort of.
It says it does not know how to "make all".

The file mod_perl.sl (see sl, not so), is not made anywhere.
So I bet my mods to Makefiles are not complete.

I googled the errors and got no where.
I looked in the mod_perl website
I looked in the installation instructions
I looked in the readme files INSTALL files
I've been looking for teeny tiny clues...for a while now.
I have seen similar text, but have not seen any answers except to GIVE UP by using precompiled versions or making mod_perl static inside apache.

Now I am sure somebody on this planet has gone through this process before.
Right?

[Steve Post]

Well I guess I should at least TRY making a fake perl from scratch. According to the website ...
http://perl.apache.org/docs/2.0/user/install/install.html#Downloading_Stable_Release_Sources

"If something goes wrong during the installation, try to repeat the installation process from scratch, while verifying all the steps with this document.
If the problem persists report the problem."

It's just that I have been down this road where I spend a ton of time to rebuild stuff from scratch only to end up at the exact same error.

So I guess the reason for this forum entry is to see where everybody else had problems when building DSO mod_perl2 with apache2.

Meanwhile, I will trudge along.

[Dennis Handly]

>But I am making the change blind because I can't see in the makefiles. (vi says "line too long).

vim will handle those long lines. Once you use vim, you may want to break up those long lines.

[Steve Post]

thanks Dennis for the suggestion. I have used vim in the past on the PC.

So far the "official" trudge through has been failing. The mod_perl warning told me to run +Accflags="+Z" when rebuilding perl. But it kills the building of perl immediately. GCC says "+Z file not found", when I try to use this. I will assume it is an invalid message for the error, and move on to rebuilding apache.

[Steve Post]

Hmmm. I installed apache 2.2.11 per the intructions already.
So let me get this straight......
I follow the instructions exactly, and mod_perl-2.0.4 DSO will NOT install into apache2.2.11.

Ok. I'll go get vim from the software and porting archive.

Hmmm.....
That needs:
dependencies: atk cairo expat fontconfig freetype gettext glib2 gtk+2 jpeg libXft libXrender libiconv libpng ncurses pango pixman tiff zlib Mesa jasper
in order to run.

I've been down this road.
Software X needs A,B,C.
Software A needs D,E,F
Software B needs G H I
software D needs ....eventually I run out of letters.

This normally results in getting a bigger disk.

[Dennis Handly]

>The mod_perl warning told me to run +Accflags="+Z" when rebuilding perl. GCC says "+Z file not found"

The gnu option for +Z is something like -fPic vs -fpic, check using "g++ --help".

[Steve Post]

Oh well. I already have -fPIC as an option. So it must not recognize it properly and incorrectly advises me to use +Z.

I see that apache2 loaded as 64bit, and I have perl as 32bit. Maybe this is the real error. I didn't do anything fancy with apache. Apache decided on its own to use 64bit.

I tried to load vim from internet express. But I would have to destroy all my other gnu software in order to put it in. But at least I can move everything to a pc (winscp), and look at that stuff there via vim or textpad.

I'll think I'll try to fail installing a static apache with mod_perl next.

steve

[Steve Post]

A static build of mod_perl also fails at gmake.

modperl_exports.c:1173:error: 'modperl_thx_interp_set' undeclared here (not in function).


But the instructions on making weren't helping.

I untar apache2 and mod_perl2.
I go to mod_perl2
I run: perl Makefile.PL MP_USE_STATIC=1 \
MP_AP_PREFIX=/ \
MP_AP_CONFIGURE="--with-mpm=prefork"
make
make test
make install

Then at this point I have ....
...I have....
.....uh.....


WHAT?
Shouldn't I do something with apache?
The make install makes what?
how does the apache source work with the thing that is not identified?

Well I didn't get that far anyway. gmake failed.

signed
Steve. the blind guy with the rubics cube.

is this it?
how about this?
is this it?

[Dennis Handly]

>I already have -fPIC as an option. So it must not recognize it properly and incorrectly advises me to use +Z.

If you are using -fPIC, you must use it on ALL compiles in the load module.
And if you don't, then ld is going to suggest the proper HP compiler option, not options for a foreign devil compiler.

[kobylka]

Hello Steve!


I just compiled Apache2 with mod_perl2 using HP C and had no errors:

Server: Apache/2.2.13 (Unix) mod_perl/2.0.4 Perl/v5.8.8


The following comes to mind...

try1.

> I run perl ./Makefile.PL
apxs is at blahblah/apache_2.2.11_pl/bin/apxs
this works but complains about +Z


It complains about +Z because you have, for sure, a statically built perl:

find / -name 'libperl*'

/usr/local/lib/perl5/5.8.8/PA-RISC2.0-thread-multi/CORE/libperl.a

But this is, depending on how perl was built, no problem when creating the mod_perl.so (check using perl -V and look at

Compiler:
cc=

if no +Z is in the cc line then you have to rebuild your perl before compiling mod_perl).


> gmake fails immediately.

What exactly is failing?


try2.

> sed 's/\.sl/\.so/g'

This command does the exact opposite of what you want.

When compiling mod_perl you can leave the Makefile unmodified and later just change the suffix of the shared lib to .sl.


Kind regards,

Kobylka

[Steve Post]

Well? Kobylka,
That sed statement is a typo in the forum entry, but not in my script. But I considered using sed to change .so to .sl a huge hint I was really screwing things up anyway.

What got me was when you told me I made perl static. Of course I made it static! Is there any other way? Well...uh...YEAH! You are right. When I rebuilt perl it asked "do you wish to use Dynamic Loading?" This time I said YES.
"name of share library [default libperl.sl]. And I chose libperl.sl.

After I built perl-5.8.8 again, I tried to build mod_perl2 as a dyanmic shared object again.
Well this time it BUILT.
I can see an apache/modules/mod_perl.sl showed up.

Now there was one other thing I did.
When I built perl before I had -fPIC in the ccflags for gcc. This time I used -fpic.

Why did I make this change? It was merely a guess. But it looks like +Z ..or is it +z is to hpux-cc as -fPIC or is it -fpic is to gcc.

I need to go over this part again. You two guys would know of a site that gives an explanation of the gcc -fPIC vs -fpic would you?


Meanwhile......
I hope I didn't jinx myself. I just got it built. But that's not the same as using it. I'll start making an apache website that uses perl.

steve

[Dennis Handly · Accepted solution]

>You two guys would know of a site that gives an explanation of the gcc -fPIC vs -fpic would you?

They should match what +Z vs +z does. Both PIC but +Z gives more linkage table entries.

[kobylka]

Hello Steve!


> But it looks like +Z ..or is it +z is to hpux-cc as -fPIC or is it -fpic is to gcc.

Yes, they both generate pic code.
Here an explanation for -f options under gcc:

http://gcc.gnu.org/onlinedocs/gcc-4.0.4/gcc/Code-Gen-Options.html#Code-Gen-Options

+z,+Z for HP C:

http://docs.hp.com/en/14672/Help/options.htm#option+capZ


Kind regards,

Kobylka

[Steve Post]

-fpic
Generate position-independent code (PIC) suitable for use in a shared library,...

-fPIC
If supported for the target machine, emit position-independent code, suitable for dynamic linking and avoiding any limit on the size of the global offset table.

So -fpic generates code.
And -fPIC emits code.
I looked up emit. To eject. To discharge. To send out. To vent. To throw out. To give out.

One makes pies. The other one throws them at me?
I'll rerun this with -fPIC anyway because that is what I was using for years.

Thanks for the help both of you.

[Dennis Handly]

>I looked up emit.

They probably shouldn't use emit because it is so close to the pronunciation of omit.

>I'll rerun this with -fPIC

+Z generates more code than +z, so if you don't have a "large" executable or shlib, you should first try +z (-fpic) then go to +Z (-fPIC) when you get the linker error.