On Nov 25, 2008, at 11:53 PM, ravi kumar wrote:
Thanks for your advice. Actually she had some requirement to build
perl5.10.0 on alpha 8.3 machine but she didn't have that machine so
she has to build that on 7.3-2 machine but she got 8.3 buildtreee in
her machine so she wants to use that buildtree to build perl5.10.0
with 8.3 sharebles since she needs symlinks should work . so please
help her guiding the proper way of doing this.
There is no "proper" way. I've heard of such things being done, but
it requires a knowledge of how the compiler, linker, and CRTL work
beyond what the documentation is likely to provide. It also will
require a knowledge of how the Perl configuration process works beyond
what one typically needs to build Perl; that part I might be able to
help with.
Symlinks involved RMS changes, not just CRTL changes, so I don't think
you can get working symlinks just by having a later CRTL. It *might*
be possible to get it built but you couldn't actually test it on an
older version of VMS. In other words, you'll need an 8.3 (or possibly
8.2?) system in order to test that what you've built actually works,
assuming you can get it to build this way at all.
As John indicated, configure.com does all sorts of probes to assess
the capabilities of the system you are building on. To do what you
are trying to do by running configure.com, you'll need to fake the
answer to F$GETSYI("VERSION") and make sure the compiler sees the
equivalent of
#define __CRTL_VER 80300000
for every test compile that it does. Those are minimum requirements.
There are very likely others I haven't thought of.
I suppose an alternative would be to manually edit config.sh to say
you have the features that you want. So, for example, the line that
looks like
d_symlink='undef'
you'd change to
d_symlink='define'
Then use munchconfig to manually regenerate config.h and the other
resulting files. This would be after configuration and before
building. None of this is documented or supported -- you'll have to
read the code in configure.com to understand how it works.
I would expect whatever approach you take will expose various
incompatibilities between your custom build environment and the
standard one, and will require a good bit of troubleshooting and
debugging to sort out.
________________________________________
Craig A. Berry
mailto:[EMAIL PROTECTED]
"... getting out of a sonnet is much more
difficult than getting in."
Brad Leithauser
