On May 27, 2007, at 3:59 PM, Ryan Schmidt wrote:
On May 26, 2007, at 04:44, Paul Guyot wrote:
On May 26, 2007, at 5:48 AM, N_Ox wrote:
The new configure flags change made in 1.4 seems to cause
problems with some ports (at least 2, maybe more).
This change introduces things like default ldflags -L/opt/local/lib.
The problem with these flags is that some ports write ENV flags
before the configure script ones.
On a port upgrade, this causes gcc to include the installed
headers instead of the distfile ones, the same goes
for ld and liking against libs.
As this is useful only if the port depends on some other ports,
why not put these defaults settings only if
the port does depend on another one?
This problem is not new and it is not related to the default
flags. For example, it occurs with ruby where, before I patched
it, the bootstrap ruby interpreter that was used was the one in /
opt/local on upgrade.
The virtual chroot technology will fix that globally, by hiding a
previous version of an installed port on upgrade. In the
meanwhile, port maintainers are invited to fix the problem on each
port. And removing ldflags is only a partial fix, as a previous
version of the software could be elsewhere on the -L path (e.g.
in /usr/).
I'm not sure how to fix this for my ports, nor even how to detect
whether it is a problem for my ports. So I would certainly
appreciate if this virtual chroot could be implemented to fix it
globally. (What's "virtual" about this chroot, by the way?)
Virtual chroot is currently implemented by Eugene Pimenov, one of the
three GSoC intern for this summer.
It consists in making ports believe the world is different from what
it really is when they are compiled. The current idea is to have the
following mapping:
/usr/bin -> /usr/bin (r/o)
/usr/sbin -> /usr/sbin (r/o)
/var -> /var
/etc -> /etc (r/o)
/tmp -> /tmp
/opt/local -> only ports declared as dependencies (r/o)
/* -> /Developer/SDKs/10.x.x/*
This is virtual because we avoid copying everything to achieve this
functionality. The plan is to do it with library injection, yet
Eugene noticed there might be some problem with non-flat namespace
libraries/tools. This is the same technology than the one used with
the trace mode.
Paul
_______________________________________________
macports-dev mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo/macports-dev
