RE: compiling modperl on alpha

[Henrik Tougaard]

> From: Didier Godefroy [mailto:[EMAIL PROTECTED]]
[...snip...]
> But in any case, trying to use perl 5.6 is nothing but trouble and if
> someone has been able to make all this work with it, I'd like 
> to know how!

We have a Perl5.6.0 with apache 1.3.14 and mod_perl 1.24_01 built with no
problems.
Did it just according to the book (which one? Don't know :)

  perl Makefile.PL EVERYTHING=1 PERL_TRACE=1
and them build httpd in the apache tree.
Works just fine.

I have tried building with DSO, but that fails miserably. Did so with
perl5.005_03 as well.

Just my EUR0.02.

Henrik Tougaard, FOA, Denmark.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: compiling modperl on alpha

[Didier Godefroy]

Hi all,

Just in case this may help others in coping with the install of mod_perl on
Tru64, here are a few more info:

After installing mod_perl 1.24_01 into Apache 1.3.14 statically on the
DU4.0b system and getting it done all the way without errors besides the
usual warnings, I found out that it really doesn't work. The perl in use on
that system is 5.6 and I think it's the source of most troubles. I built
mod_perl like this:

CC="cc"
export CC
perl Makefile.PL \
 APACHE_SRC=../apache/src \
 EVERYTHING=1 \
 PERL_TRACE=1 \
 USE_APACI=1 \
 DO_HTTPD=1 \
 PREP_HTTPD=1

just like we should (I think), then did the make and make install but I
skipped the make test, which never worked. I installed apache with modperl
static and all other standard modules as DSOs, then added php4 as a DSO
afterwards. PHP4 "kinda" worked because a simple page giving out its status
info actually does work, but modperl doesn't. I don't really want to roll
back perl on that system, it has too many users and too much traffic to mess
with it that way.
I did however try this same thing on the Tru64 5.1 system and same thing,
PHP ended up working (at least for a while) but modperl just wouldn't work.
So I rolled back to perl 5.00501 and did the whole thing from scratch, using
the same script as above on the modperl side, with the make and make install
(skipping test) then did the build of apache with:

CC="cc" \
CFLAGS="-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64" \
./configure \
"--with-layout=config.mylayout:MyApache" \
"--activate-module=src/modules/perl/libperl.a" \
"--server-uid=httpd" \
"--server-gid=httpd" \
"--enable-module=most" \
"--enable-module=perl" \
"--enable-shared=max" \
"--disable-shared=perl"

and a couple of other things like suexec. I haven't tried to use modperl as
a DSO on that system again, so I'm not sure it would work or not.
I also added PHP4 as a DSO after the install and that worked (also for a
while) and modperl seems now to be working. The only problem I have to solve
now is "why the heck did php work for a while then stopped working because
of some unresolved symbol without changing anything in the config"!
Beats me! I haven't found that out yet, even after re-building php from
scratch again twice, it still won't work because of that un-resolved symbol
"php_sig_gif". Other than that the modperl/apache tandem seems ok for now
and I hope I can resolve this php thing without having to rebuild the whole
thing. (if anyone knows about this un-resolved symbol, give me a hint..)

But in any case, trying to use perl 5.6 is nothing but trouble and if
someone has been able to make all this work with it, I'd like to know how!

-- 
Didier Godefroy
mailto:[EMAIL PROTECTED]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: compiling modperl on alpha

[Didier Godefroy]

>> Try getting rid of Perl 5.6 and using 5.005.  This has worked for me and for
>> several other folks running other flavors of Unix.
> 
> Weird, but compiled 5.6 perl with default options does not mesh well with
> mod_perl, however I run Mandrake Linux, and 5.6 precompiled for this
> platform, seem to integrate into mod_perl somewhat seamlessly. I suppose
> if you want 5.6 with mod_perl you gotta ask Mandrake folks for compile
> time options.

I finally got frustrated enough to try not using 5.6 and I had to install
5.005 in there, but it didn't make any difference, the tests on modperl
still won't work. It always does the same thing, no matter which perl is
being used, http starts and keeps running but the test on the warm up before
doing the actual tests always fails and there is nothing in the error log of
any use.
What the heck is the problem with it?
Nothing ever works as it says in the docs! Following the steps to the letter
is always insufficient, there is always some tinkering to do and it's not
that obvious to figure it out..

-- 
Didier Godefroy
mailto:[EMAIL PROTECTED]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: compiling modperl on alpha

[Rafael Caceres]

Didier:

I had no trouble compiling mod_perl (with SSL and Frontpage support) on 
4.0B and 4.0D True64.
The script used on the mod_perl side is:

#!/bin/sh
perl Makefile.PL \
 APACHE_SRC=../apache_1.3.12/src \
 SSL_BASE=../openssl-0.9.5a \
 DO_HTTPD=1 \
 USE_APACI=1 \
 PREP_HTTPD=1 \
 EVERYTHING=1
make
make test
###
and on the Apache (1.3.12) side:

#!/bin/sh
SSL_BASE=../openssl-0.9.5a \
./configure --prefix=/usr/local/apache \
 --enable-module=ssl \
 --activate-module=src/modules/perl/libperl.a \
 --activate-module=src/modules/extra/mod_frontpage.o
make
make certificate
make install
###

It's worked like a charm. I guess that perl 5.6 differences appart, it 
should work.

Regards,
Rafael Caceres

At 07:24 PM 11/16/00 -0500, you wrote:
>Hi all,
>
>maybe somebody can shed some light on this:
>
>I'm trying to compile mod_perl as a dso with apxs on Alpha/Tru64 unix and
>there is an error from the linker:
>
>ld -shared -expect_unresolved "*" -O4 -msym -std -s -L/usr/local/lib -o
>libperl.so mod_perl.lo perlxsi.lo perl_config.lo perl_util.l
>o perlio.lo mod_perl_opmask.lo  Apache.lo Constants.lo ModuleConfig.lo
>Log.lo URI.lo Util.lo Connection.lo Server.lo File.lo Table.l
>o -Wl,-rpath,/usr/local/lib/perl5/5.6.0/alpha-dec_osf/CORE  -L/usr/local/lib
>/usr/local/lib/perl5/5.6.0/alpha-dec_osf/auto/DynaLoade
>r/DynaLoader.a -L/usr/local/lib/perl5/5.6.0/alpha-dec_osf/CORE -lperl -lbind
>-ldbm -ldb -lm -liconv
>ld:
>Invalid flag usage: Wl,-rpath,/usr/local/lib/perl5/5.6.0/alpha-dec_osf/CORE,
>-Wx,-option must appear after -_SYSTYPE_SVR4
>ld: Usage: ld [options] file [...]
>*** Exit 1
>
>Where would this flag be defined? How can this be fixed?
>I tried this on both a Tru64 5.1 and an older DU4.0b and the error is the
>same.
>
>Can anyone give a clue?
>
>--
>Didier Godefroy
>mailto:[EMAIL PROTECTED]



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: compiling modperl on alpha

[Didier Godefroy]

Here is an other one:

I finally got mod_perl statically compiled and installed with apache.
I didn't run the tests on mod_perl as they fail every time, maybe it has
something to do with what's going on now, I'm not sure. When I try to run
one of those test scripts that come with apache in the cgi-bin, only the one
with the shell works, not the perl one. I tried disabling suexec then
mod_perl, but it doesn't change anything with both disabled. CGI works but
not with perl, and I even tried it with tcl and the result is the same with
tcl and with perl. Using bash or sh work fine. The perl script printenv runs
manually on the system but not as a cgi. I checked and double checked the
permissions and ownerships, especially since I was trying to get suexec
enabled, I think I got all that right (I never used suexec before), but it
makes no difference anyway, because I disabled it and it's the same thing.
I looked of course in the error logs, including cgierrors, nothing useful
there, it only reports a 500 error (premature end of script headers) and
nothing more, even with loglevel at debug and the -w perl warnings on.
What could I be missing???

-- 
Didier Godefroy
mailto:[EMAIL PROTECTED]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: compiling modperl on alpha

[spam]

On Fri, 17 Nov 2000, Jimi Thompson wrote:

> Try getting rid of Perl 5.6 and using 5.005.  This has worked for me and for
> several other folks running other flavors of Unix.

Weird, but compiled 5.6 perl with default options does not mesh well with
mod_perl, however I run Mandrake Linux, and 5.6 precompiled for this
platform, seem to integrate into mod_perl somewhat seamlessly. I suppose
if you want 5.6 with mod_perl you gotta ask Mandrake folks for compile
time options.
just 2c
Pavel


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: compiling modperl on alpha

[Didier Godefroy]

on 11/17/00 3:48 PM, [EMAIL PROTECTED] at [EMAIL PROTECTED] uttered the
following:

>> ld -shared -expect_unresolved "*" -O4 -msym -std -s -L/usr/local/lib -o
> 
> For whatever reason, it's trying to build a dso.  I'd double check my
> settings.

You were right, it must be because I had --enable-shared=max in there, maybe
it applied that to the extra mod_perl, so I added a --disable-shared=perl
and that error is gone, and the make goes all the way now...

-- 
Didier Godefroy
mailto:[EMAIL PROTECTED]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: compiling modperl on alpha

[kevinr]

> ld -shared -expect_unresolved "*" -O4 -msym -std -s -L/usr/local/lib -o

For whatever reason, it's trying to build a dso.  I'd double check my
settings.

Kevin Riggins

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: compiling modperl on alpha

[Jimi Thompson]

Try getting rid of Perl 5.6 and using 5.005.  This has worked for me and for
several other folks running other flavors of Unix.

Didier Godefroy wrote:

> More troubles in this saga to install mod_perl with apache:
>
> After building mod_perl static with apache on DU4.0b and getting no errors
> (so far), I tried the same thing on Tru64 5.1 and I'm still getting this:
>
> ld -shared -expect_unresolved "*" -O4 -msym -std -s -L/usr/local/lib -o
> libperl.so mod_perl.lo perlxsi.lo perl_config.lo perl_util.l
> o perlio.lo mod_perl_opmask.lo  Apache.lo Constants.lo ModuleConfig.lo
> Log.lo URI.lo Util.lo Connection.lo Server.lo File.lo Table.l
> o -Wl,-rpath,/usr/local/lib/perl5/5.6.0/alpha-dec_osf/CORE  -L/usr/local/lib
> /usr/local/lib/perl5/5.6.0/alpha-dec_osf/auto/DynaLoade
> r/DynaLoader.a -L/usr/local/lib/perl5/5.6.0/alpha-dec_osf/CORE -lperl -lbind
> -lgdbm -ldbm -ldb -lm -liconv
> ld:
> Invalid flag usage: Wl,-rpath,/usr/local/lib/perl5/5.6.0/alpha-dec_osf/CORE,
> -Wx,-option must appear after -_SYSTYPE_SVR4
> ld: Usage: ld [options] file [...]
>
> I'm trying again to do it static, I thought that stuff wasn't used in the
> static build! What could be the difference between DU4.0b and Tru64 5.1 that
> could cause this?
> Both systems have Perl 5.6.0 installed (from source), I'm using cc and there
> is no GNU ld in either. Apache is 1.3.14 and mod_perl 1.24_01
>
> --
> Didier Godefroy
> mailto:[EMAIL PROTECTED]
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]

--
Jimi Thompson
Web Master
L3 communications

"It's the same thing we do every night, Pinky."




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: compiling modperl on alpha

[Didier Godefroy]

on 11/17/00 1:20 PM, Jimi Thompson at [EMAIL PROTECTED] uttered the
following:

> I suspect that this has something to do with using Perl 5.6.0.  I and several
> others have had problems getting mod_perl to work with this version of Perl
> under
> various flavors of Unix (Solaris, AIX, HP-UX).  We have all also found that if
> you
> roll Perl back to 5.005 that this appears to solve the problem.

Actually, I just compiled mod_perl with apache (static) and bypassed the
tests, I only did the make and install of mod_perl then did apache, doing no
tests anywhere, and it worked!!! But I have to do some testing of the perl
module, everything seems to work fine but I don't know if mod_perl will work
right...
The install I just did was on the older DU4.0b system, now I'll try the same
thing on the new Tru64 5.1 and we'll see what happens.

What would be a good enough test to make sure mod_perl works right?

-- 
Didier Godefroy
mailto:[EMAIL PROTECTED]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: compiling modperl on alpha

[Jimi Thompson]

I suspect that this has something to do with using Perl 5.6.0.  I and several
others have had problems getting mod_perl to work with this version of Perl under
various flavors of Unix (Solaris, AIX, HP-UX).  We have all also found that if you
roll Perl back to 5.005 that this appears to solve the problem.

"Jeremy A. Mates" wrote:

> On Thu, 16 Nov 2000, Didier Godefroy wrote:
> > GNU ld isn't on either system and the error is the exact same on both,
> > they seem to all this in common:
> >
> > -Wl,-rpath,/usr/local/lib/perl5/5.6.0/alpha-dec_osf/CORE'
> [snip]
> > dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='
> > -Wl,-rpath,/usr/local/lib/perl5/5.6.0/alpha-dec_osf/CORE'
> > cccdlflags=' ', lddlflags='-shared -expect_unresolved "*" -O4 -msym -std
> > -s -L/usr/local/lib'
>
> Hmmm... the Digitals I have share similar ccdlflags statements.  Did you
> install perl 5.6.0 from scratch or via a package of some kind?  (If via
> package, the people who built the package may have used a different ld or
> had different environment settings from yours.)
>
> You might be able to pass the flag ld appeared to be complaining about
> with the following trick:
>
> $ LDFLAGS="-_SYSTYPE_SVR4" command_that_fails
>
> Which should work for Bourne-related shells.  The ld man page didn't
> appear contain anything useful, so I'm guessing moreso than usual at this
> point. :)
>
> You could also try asking on the tru64-unix-managers list:
>
> http://www.ornl.gov/cts/archives/mailing-lists/
>
> 
>
> > What is the problem with doing that? I tried compiling it statically
> > first, but I get other types of errors when running the tests, it
> > always fails. The httpd is running but the tests won't, and the log
> > doesn't say anything that helps to find out why. What other choices
> > are there then?
>
> If static fails, then you can probably get away with DSO if you keep the
> httpd process memory usage down with various directives.  There's more on
> this just recently in this list's archives, as I recall...
>
> --
> Jeremy Mates
> http://www.sial.org/

--
Jimi Thompson
Web Master
L3 communications

"It's the same thing we do every night, Pinky."




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: compiling modperl on alpha

[Didier Godefroy]

on 11/17/00 8:35 AM, [EMAIL PROTECTED] at [EMAIL PROTECTED] uttered the
following:

> When building static, I use the following:
> 
> Configuring and compile mod_perl:
> 
> $ perl Makefile.PL \
>> APACHE_SRC=../apache_x.x.x/src \
>> USE_APACI=1 \
>> DO_HTTPD=1 \
>> EVERYTHING=1 \
>> PREP_HTTPD=1
> $ make

That's exactly what I was doing, but the make test fails, and since I don't
even know why and the tests didn't run, I didn't dare going to the next
step..

I'll try it again, and if the test don't run, I'll still try to go ahead,
but how can it be tested after install to make sure it works?

-- 
Didier Godefroy
mailto:[EMAIL PROTECTED]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: compiling modperl on alpha

[Didier Godefroy]

on 11/17/00 8:10 AM, [EMAIL PROTECTED] at [EMAIL PROTECTED] uttered the
following:

> supported by ld.  In order to get it to compile I edited
> $APACHE_SRC/src/modules/perl/Makefile after running configure and added the
> -rpath  stuff without the comma to the LDFLAGS variables and removed all

This is assuming a static compile, but I'm trying to do a dso now...
Anyway, when I tried to do a static, I didn't get such ld errors, it
compiled all the way and the problem was with the tests, which wouldn't even
run because it found the httpd not working, although httpd was actually up
and when it tries to do the tests, it starts it, waits for it to warm up and
finds it running because it says "done" after a moment, so httpd does start,
but once the tests try to check on httpd for the second time before actually
running the tests, it gives an error because it can't get a reply from
httpd. The log file doesn't give anything useful to track this down and the
httpd that was started stays in there running...
I would prefer having mod_perl static anyway, if I could get it to pass the
tests, it would be a good thing...

-- 
Didier Godefroy
mailto:[EMAIL PROTECTED]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: compiling modperl on alpha

[kevinr]

The -Wl flag is used to cause the rpath part to be passed on the ld
stage of compiling if it is called with cc.  The man pages for cc explain it
in better detail.  The problem is that the Makefile for mod_perl in
$APACHE_SRC/src/modules/perl calls ld directly and the -Wl flag is not
supported by ld.  In order to get it to compile I edited
$APACHE_SRC/src/modules/perl/Makefile after running configure and added the
-rpath  stuff without the comma to the LDFLAGS variables and removed all
the -Wls.

Example:

LDFLAGS = 
SOMETHING = -Wl,rpath,...

to 

LDFLAGS = -rpath  .
SOMETHING = -rpath 

This let it compile, but I never could get it to actually work.  Kept
getting undefined errors on things like PL_perl_destruct_level and such.

Pleaes let me know if you actually get it to work.
Kevin Riggins
Dice.com
-Original Message-
From: Didier Godefroy [mailto:[EMAIL PROTECTED]]
Sent: Thursday, November 16, 2000 8:31 PM
To: Jeremy A. Mates
Cc: [EMAIL PROTECTED]
Subject: Re: compiling modperl on alpha


on 11/16/00 8:50 PM, Jeremy A. Mates at [EMAIL PROTECTED] uttered the
following:

> Make sure the ld that is being called is the exact same one that was used
> to build perl itself, e.g. by altering your PATH environment variable to
> point to either the vendor default first (under /usr/bin) or perhaps to
> the GNU ld that might have gotten installed somewhere under /freeware/bin
> or /usr/local/bin.

GNU ld isn't on either system and the error is the exact same on both, they
seem to all this in common:

-Wl,-rpath,/usr/local/lib/perl5/5.6.0/alpha-dec_osf/CORE'

> Configure script; you can run `perl -V` to show what the flags are on the
> perl binary earliest in your PATH.  Changing the ld binary used or ld

here it is:

perl -V
Summary of my perl5 (revision 5.0 version 6 subversion 0) configuration:
  Platform:
osname=dec_osf, osvers=4.0, archname=alpha-dec_osf
uname='osf1 ulysium.ulysium.net v4.0 564 alpha '
config_args=''
hint=recommended, useposix=true, d_sigaction=define
usethreads=undef use5005threads=undef useithreads=undef
usemultiplicity=undef
useperlio=undef d_sfio=undef uselargefiles=define
use64bitint=define use64bitall=define uselongdouble=define
usesocks=undef
  Compiler:
cc='cc', optimize='-O4', gccversion=
cppflags='-std -ieee -D_INTRINSICS -I/usr/local/include -DLANGUAGE_C'
ccflags ='-std -fprm d -ieee -D_INTRINSICS -I/usr/local/include
-DLANGUAGE_C'
stdchar='unsigned char', d_stdstdio=define, usevfork=false
intsize=4, longsize=8, ptrsize=8, doublesize=8
d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=8
ivtype='long', ivsize=8, nvtype='long double', nvsize=8, Off_t='off_t',
lseeksize=8
alignbytes=8, usemymalloc=n, prototype=define
  Linker and Libraries:
ld='ld', ldflags =' -L/usr/local/lib'
libpth=/usr/local/lib /usr/shlib /usr/ccs/lib /usr/lib/cmplrs/cc
/usr/lib /var/shlib
libs=-lbind -ldbm -ldb -lm -liconv
libc=/usr/shlib/libc.so, so=so, useshrplib=true, libperl=libperl.so
  Dynamic Linking:
dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='
-Wl,-rpath,/usr/local/lib/perl5/5.6.0/alpha-dec_osf/CORE'
cccdlflags=' ', lddlflags='-shared -expect_unresolved "*" -O4 -msym -std
-s -L/usr/local/lib'

Characteristics of this binary (from libperl):
  Compile-time options: USE_64_BIT_INT USE_64_BIT_ALL USE_LARGE_FILES
  Built under dec_osf


At first when I tried building mod_perl, it complained about the large file
support no being in apache, so I recompiled apache for that.

> Also note that mod_perl as a DSO isn't recommended by the mod_perl
> documentation...

What is the problem with doing that?
I tried compiling it statically first, but I get other types of errors when
running the tests, it always fails. The httpd is running but the tests
won't, and the log doesn't say anything that helps to find out why. What
other choices are there then?

-- 
Didier Godefroy
mailto:[EMAIL PROTECTED]

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: compiling modperl on alpha

[Jeremy A. Mates]

On Thu, 16 Nov 2000, Didier Godefroy wrote:
> GNU ld isn't on either system and the error is the exact same on both,
> they seem to all this in common:
>
> -Wl,-rpath,/usr/local/lib/perl5/5.6.0/alpha-dec_osf/CORE'
[snip]
> dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='
> -Wl,-rpath,/usr/local/lib/perl5/5.6.0/alpha-dec_osf/CORE'
> cccdlflags=' ', lddlflags='-shared -expect_unresolved "*" -O4 -msym -std
> -s -L/usr/local/lib'

Hmmm... the Digitals I have share similar ccdlflags statements.  Did you
install perl 5.6.0 from scratch or via a package of some kind?  (If via
package, the people who built the package may have used a different ld or
had different environment settings from yours.)

You might be able to pass the flag ld appeared to be complaining about
with the following trick:

$ LDFLAGS="-_SYSTYPE_SVR4" command_that_fails

Which should work for Bourne-related shells.  The ld man page didn't
appear contain anything useful, so I'm guessing moreso than usual at this
point. :)

You could also try asking on the tru64-unix-managers list:

http://www.ornl.gov/cts/archives/mailing-lists/



> What is the problem with doing that? I tried compiling it statically
> first, but I get other types of errors when running the tests, it
> always fails. The httpd is running but the tests won't, and the log
> doesn't say anything that helps to find out why. What other choices
> are there then?

If static fails, then you can probably get away with DSO if you keep the
httpd process memory usage down with various directives.  There's more on
this just recently in this list's archives, as I recall...

-- 
Jeremy Mates
http://www.sial.org/

Re: compiling modperl on alpha

[Didier Godefroy]

on 11/16/00 8:50 PM, Jeremy A. Mates at [EMAIL PROTECTED] uttered the
following:

> Make sure the ld that is being called is the exact same one that was used
> to build perl itself, e.g. by altering your PATH environment variable to
> point to either the vendor default first (under /usr/bin) or perhaps to
> the GNU ld that might have gotten installed somewhere under /freeware/bin
> or /usr/local/bin.

GNU ld isn't on either system and the error is the exact same on both, they
seem to all this in common:

-Wl,-rpath,/usr/local/lib/perl5/5.6.0/alpha-dec_osf/CORE'

> Configure script; you can run `perl -V` to show what the flags are on the
> perl binary earliest in your PATH.  Changing the ld binary used or ld

here it is:

perl -V
Summary of my perl5 (revision 5.0 version 6 subversion 0) configuration:
  Platform:
osname=dec_osf, osvers=4.0, archname=alpha-dec_osf
uname='osf1 ulysium.ulysium.net v4.0 564 alpha '
config_args=''
hint=recommended, useposix=true, d_sigaction=define
usethreads=undef use5005threads=undef useithreads=undef
usemultiplicity=undef
useperlio=undef d_sfio=undef uselargefiles=define
use64bitint=define use64bitall=define uselongdouble=define
usesocks=undef
  Compiler:
cc='cc', optimize='-O4', gccversion=
cppflags='-std -ieee -D_INTRINSICS -I/usr/local/include -DLANGUAGE_C'
ccflags ='-std -fprm d -ieee -D_INTRINSICS -I/usr/local/include
-DLANGUAGE_C'
stdchar='unsigned char', d_stdstdio=define, usevfork=false
intsize=4, longsize=8, ptrsize=8, doublesize=8
d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=8
ivtype='long', ivsize=8, nvtype='long double', nvsize=8, Off_t='off_t',
lseeksize=8
alignbytes=8, usemymalloc=n, prototype=define
  Linker and Libraries:
ld='ld', ldflags =' -L/usr/local/lib'
libpth=/usr/local/lib /usr/shlib /usr/ccs/lib /usr/lib/cmplrs/cc
/usr/lib /var/shlib
libs=-lbind -ldbm -ldb -lm -liconv
libc=/usr/shlib/libc.so, so=so, useshrplib=true, libperl=libperl.so
  Dynamic Linking:
dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='
-Wl,-rpath,/usr/local/lib/perl5/5.6.0/alpha-dec_osf/CORE'
cccdlflags=' ', lddlflags='-shared -expect_unresolved "*" -O4 -msym -std
-s -L/usr/local/lib'

Characteristics of this binary (from libperl):
  Compile-time options: USE_64_BIT_INT USE_64_BIT_ALL USE_LARGE_FILES
  Built under dec_osf


At first when I tried building mod_perl, it complained about the large file
support no being in apache, so I recompiled apache for that.

> Also note that mod_perl as a DSO isn't recommended by the mod_perl
> documentation...

What is the problem with doing that?
I tried compiling it statically first, but I get other types of errors when
running the tests, it always fails. The httpd is running but the tests
won't, and the log doesn't say anything that helps to find out why. What
other choices are there then?

-- 
Didier Godefroy
mailto:[EMAIL PROTECTED]

Re: compiling modperl on alpha

[Jeremy A. Mates]

On Thu, 16 Nov 2000, Didier Godefroy wrote:
> I'm trying to compile mod_perl as a dso with apxs on Alpha/Tru64 unix and
> there is an error from the linker:
[snip]
> Can anyone give a clue?

Make sure the ld that is being called is the exact same one that was used
to build perl itself, e.g. by altering your PATH environment variable to
point to either the vendor default first (under /usr/bin) or perhaps to
the GNU ld that might have gotten installed somewhere under /freeware/bin
or /usr/local/bin.

ld flags are usually set during the compilation of perl using the
Configure script; you can run `perl -V` to show what the flags are on the
perl binary earliest in your PATH.  Changing the ld binary used or ld
flags generally involves a manual recompilation of all things perl. :-/

Also note that mod_perl as a DSO isn't recommended by the mod_perl
documentation...

-- 
Jeremy Mates
http://www.sial.org/