About new default configure-{c(pp|xx)?,ld}flags

[Ryan Schmidt]

On Jun 11, 2007, at 03:37, Paul Guyot wrote:

> 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.

Thanks for the explanation, Paul:

> 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.

Ah, I understand.

> The plan is to do it with library injection,

I'm not sure what this means..? The above paths would be made  
available to the chroot environment... by hard links? or how? And how  
do you make those certain areas read-only?

> 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.

Ah, ok. I was wondering how trace mode figured out what it figured  
out (though I hadn't been so interested that I tried to find the  
source code yet).