Re: how to link compiler logical from mmk

[email protected] ("Craig A. Berry")
Newsgroups perl.vmsperl
Message-ID <[email protected]>
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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.