port install gnat-gcc

[Boey Maun Suang]

Hi Ryan,

On 16/06/2009, at 8:18 PM, Ryan Schmidt wrote:

> On Jun 15, 2009, at 00:36, Boey Maun Suang wrote:
>
>> If it's of any interest to anyone, I've been having a go at  
>> creating a port that builds in the recommended way by downloading a  
>> bootstrap compiler and uses that to build GCC with Ada support, as  
>> the ghc port does.  (Because of the way that GCC builds and  
>> installs itself with absolute path references, the only way that I  
>> can see to get that to work would be to have the bootstrap built  
>> for installation into a temporary subdirectory of /var/tmp, have  
>> that build and install GCC with Ada support on the local machine,  
>> and then delete the bootstrap compiler -- though that may mean that  
>> it won't work with trace mode on).
>
> Why /var/tmp and not ${destroot}?


I know what I want to say, but I'm not sure about the best way to  
explain it, so please ask questions about anything that isn't clear.   
I also apologise for the redundancy if I mention anything that you  
already know about.

Firstly, I just want to make clear that it's the bootstrap compiler  
that I'm talking about extracting into a subdirectory of /var/tmp, for  
use to build and install a new GCC into ${prefix}.  That is, during  
the extract phase, the bootstrap compiler gets extracted into  
subdirectory of /var/tmp, and the source gets extracted into $ 
{workpath} as usual; the configure and build phases will then use the  
bootstrap in /var/tmp to build a new GCC that will be destrooted into $ 
{destroot}${prefix} and finally installed into ${prefix}.

The problem is that the GCC build process requires its final install  
prefix to be an absolute one; configure refuses to accept any relative  
components in the argument to --prefix.  Consequently, all of the path  
references within the files in any GCC build are absolute ones.  This  
includes references to required dynamic libraries, but there are  
probably other path references elsewhere that I haven't yet found  
(e.g. in internal configuration files).  It is the latter that means  
that I cannot be sure that changing the paths to dynamic libraries in  
GCC's executables and dynamic libraries using install_name_tool will  
be sufficient; that could break the compiler in ways that are not easy  
to detect or fix.

Thus, to be sure that a build of GCC can be reliably used as a  
bootstrap compiler, it has to be installed (temporarily) in the same  
absolute location on every machine.  ${destroot} won't work because it  
depends on ${prefix}, which is allowed to vary.  The bootstrap  
compiler also needs to be installed in a place where we can be sure  
that it won't interfere with other parts of the system, and can be  
easily deleted when it's finished with, and as far as I know, /var/tmp  
is the best place for such things.

(Of course, one could theoretically change the GCC build process to  
enable it to accept relative path installations, but I'm confident  
that that would be far more effort than it would be worth.  It's  
certainly beyond my ability and pain threshold.)

Consequently, I can't see any relative location to which we can  
extract a GCC bootstrap, and /var/tmp is the best absolute path that I  
can think of for this purpose.

Incidentally, I used otool on the executables in the current ghc  
bootstrap compiler, and they contain _absolute_ references to /opt/ 
local/lib/libgmp.3.dylib, so for those who try to install MacPorts ghc  
and who have configured ${prefix} to be other than /opt/local, the  
build will either fail due to the non-existence of /opt/local/lib/ 
libgmp.3.dylib, or (in accordance with the dyld(1) man page's  
description of the DYLD_LIBRARY_PATH and DYLD_FALLBACK_LIBRARY_PATH  
variables), it will silently pick up libgmp.3.dylib in another  
location, such as /usr/local/lib, when it is run.  I haven't looked  
into it, but we may find that the ghc bootstrap actually has this same  
problem, just not in such an obvious or severe form.

As always, your thoughts (and those of others on the list) would be  
appreciated.

Kind regards,


Maun Suang

-- 
Boey Maun Suang
Email: boeyms at macports dot org