Hi Bruce and Autrijus,
as I wrote before, the -l patch does *not* solve all problems yet.
Basically, the following 2 issues remain unsolved:
1. setting LD_LIBRARY_PATH inside the bootstrap executable does
not seem to help at all - because the runtime linker for dynamic objects
is in action already (and I don't know how to extent its search scope
once it's instantiated).
2. For dynamic libraries which are used by the minimum boot loader itself,
the concept does not work. libc might be the hardest-to-get-working
example here (unless you link with a static libc, which may have
drawbacks regarding portability). I got a similar problem with libz.so
(which is not installed on our Solaris hosts, but needed by
Compress::Zlib, which is needed by the boot loader's Archive::Zip ...).
The "intermediate/personal solution" for me was to construct a Compress::Zlib
which has all .o files of libz.so "on board" ...
However, scanning the "dl*" Solaris man pages, I wonder whether
"dldump" could be applied somehow to construct "selfcontaining Perl .so files"
dynamically when packing the PAR file - this could be another approach
to cure some of the shlib problems.
Best regards,
Markus
Bruce Winter wrote:
... snip ...
>
>> Now I've got a different problem when I run the resulting binary on a
>> different linux box. I get this message:
>>
>> [EMAIL PROTECTED] bin]$ /projects/public/a.out
>> /projects/public/a.out: /lib/libc.so.6: version `GLIBC_2.3' not found
>> (required by /projects/public/a.out)
>>
>> In fact, I'll get this even with the simplest of script. I tried it on
>> both a RH 5.2 and RH 7.2 box. I think the newer libraries I have
>> on the RH
>> 8.0 box I compiled it on are somehow not compatable? I tried various
>> combinations of -l files, but I think this happens right away,
>> before the pp
>> generated binary can do anything.
>
>I discovered I can run pp binaries I compile on my Red Hat 7.2 box on my Red
>Hat 8.0 box, but not the other way around, due to the GLIBC errors above.
>
>> > > > If somebody on Win32 can help testing / porting the shlib support to
>> > > > that platform, I'll gladly merge it earlier.
>> > >
>> > > I can give Win32 a spin also, except I think the latest
>> version that PPM
>> > > gave me there was 0.63, so the patches wouldn't apply. What is
>> > the best way
>> > > to check version number?
>> >
>> > Well if you have MSVC++ (which you will need to compile shlib support
>> > anyway) just download the snap and compile it there.
>> >
>> > If you don't... I'll try putting up a binary for you tomorrow.
>>
>> Sorry, I don't have any windows C compilers installed here. I'd
>> by happy to
>> test out your recent updates once you get an updated binary.
>
>When I installed 0.66 on my windows box, I did not get the 'try the
>experimental shlib' option, so I wasn't able to test this yet. Trying
>the -l option seemed to invoke -log instead.
>
>Bruce
>
--
Markus Jansen Senior IS/IT Support Engineer, EED/IT
Ericsson Eurolab Deutschland GmbH Email : [EMAIL PROTECTED]
Ericsson Allee 1 Phone : +49 2407 575 5157
52134 Herzogenrath Fax : +49 2407 575 7289
Germany Mobile: +49 172 274 2003
