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
_______________________________________________
macports-users mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
