perl-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stas Bekman <s...@stason.org>
Subject Re: OBSD update
Date Tue, 06 May 2003 06:52:46 GMT

>>Yup, I have 64. Do you have to reboot after changing this setting? (It's not 
>>my machine, It's Carl who let's me mess with it).
> 
> 
> 
> Once changed, just logout/login and it is there.
> 
> you can check that it worked with
> 
> $> ulimit -n
> 128

Yup, I've found the manpage ;)

I've tried:

% ulimit -n 256

but in vain. I've tried raising other limits, but no change.

>>>>>5. LD_LIBRARY_PATH. This one is the only one I don't understand quite
>>>>>yet. By default, it's set to /usr/local/lib:/usr/X11R6/lib on my
>>>>>machine. And the perl that ships with my OpenBSD will simply segfault
in
>>>>>a completely bogus way:
>>>>>
>>>>>(gdb) bt
>>>>>#0  0x400078cf in end ()
>>>>>#1  0x40013060 in end ()
>>>>>#2  0x400074a8 in end ()
>>>>>#3  0x40007182 in end ()
>>>>>#4  0x400085bd in end ()
>>>>>
>>>>>The secret to fixing it for me so far, has been to make sure
>>>>>/usr/X11R6/lib isn't in my LD_LIBRARY_PATH. At this point, all attempts
>>>>>to figure out WHY have failed miserably.
>>>>
>>>>You have to specify it explicitly when you invoke your mod_perl. We probably

>>>>should supply a support for this from within Apache::Test.
>>>
>>>
>>>Well, I was also planning on doing some more digging on the strange
>>>segfaults I've been seeing with /usr/X11R6/lib, but it's very strange,
>>>IMO.
>>
>>IMHO, overriding LD_LIBRARY_PATH is probably the simplest. At least for the 
>>tests.
> 
> 
> Well, more or less. For example, on my setup, you need to keep
> /usr/local/lib and 'know' to remove /usr/X11R6/bin ...
> 
> 
>>What I don't understand why the perl executable picks wrong libraries - they 
>>don't even much on the version numbers. Without LD_LIBRARY_PATH it complains:
>>
>>/usr/libexec/ld.so: warning: libperl.so.6.0: minor version >= 1 expected, 
>>using it anyway
>>
>>why "using anyway"....
> 
> 
> You can try setting
> LD_TRACE_LOADED_OBJECTS=1
> 
> to get a more detailled of what ld loaded ...

and LD_DEBUG=1 ;)

The thing is, it has no clue about the 
/data/stas/perl/5.6.1/lib/5.6.1/OpenBSD.i386-openbsd/CORE/ path, I though the 
perl executable should at least try that one first unless overriden with an 
explicit LD_LIBRARY_PATH, but apparently it totaly ignores it.

>>It also looks like it doesn't like LD_PRELOAD:
>>
>>cd perl-5.6.1
>>LD_PRELOAD=`pwd`/libperl.so LD_LIBRARY_PATH=`pwd` make test
>>/usr/libexec/ld.so: preload: /data/stas/perl.org/perl-5.6.1/libperl.so: cannot 
>>map object
>>
> 
> 
> On a funnier note, I've found where RANLIB comes from
> 
> linux #> perl -V:ranlib
> ':'
> openbsd $> perl -V:ranlib
> 'ranlib'
> 
> So we are getting it from Config.pm, but annoyingly enough, it says to
> use ranlib even though we don't want to.
> 
> So, after all, maybe the DARWIN hack is for the same reason...

In that case, go with it.

__________________________________________________________________
Stas Bekman            JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/     mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org   http://ticketmaster.com


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org


Mime
View raw message