About new default configure-{c(pp|xx)?,ld}flags
Hello, 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? -- Anthony Ramine, a lazy french student. nox@macports.org
On May 26, 2007, at 5:48 AM, N_Ox wrote:
Hello,
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/). Paul -- http://paul-guyot.com/
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?)
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
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).
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?
Library injection means that open(2), write(2) and so on are patched with our own versions and that's how we trick the ports, by returning ENOENT, EACCES, etc. On darwin, the technique consists in setting DYLD_INSERT_LIBRARIES and DYLD_FORCE_FLAT_NAMESPACE. Paul
participants (3)
-
N_Ox
-
Paul Guyot
-
Ryan Schmidt