Bug 140606 – Option to merge compile-time deps to $ROOT

• Product: Portage Development
• Status: RESOLVED WORKSFORME

[Description James Le Cuirot 2006-07-16 02:45:04 UTC]

Some of the new $ROOT stuff that's gone into Portage lately is fantastic but I'm still having some problems when cross-building in practise. I've written some cross-compile wrappers to get around some of the common issues. One very important thing I make use of is gcc's --sysroot option. As far as include paths are concerned, it only seems to affect the default paths, not those additionally specified with -I, so my wrappers prepend $ROOT to those as well.

The problem with this is that it requires any includes to be in $ROOT rather than /. This is okay when the include files have been bundled with a run-time library but not when they are in a package on their own - such as with the x11-proto packages.

To try and workaround this, I give gcc a "second chance" where it runs a second time without prepending $ROOT to the -I arguments. This occasionally works but it usually fails. Firstly, most includes are searched relative to /usr/include and secondly, there is usually a conflict between the headers in / and the headers in $ROOT. If I try adding -I/usr/include, the conflicting header problem generally gets worse.

What this all boils down to is that it would be nice for Portage to have an option whereby it would merge compile-time dependencies to $ROOT as well as /. I was initially going to say "instead of" rather than "as well as" but of course, this would not work when the compile-time dependency is actually needed for an executable such as bison. Unfortunately, it is infeasible for us determine the exact nature of each compile-time dependency.

[Comment 1 Zac Medico 2006-07-16 10:06:47 UTC]

(In reply to comment #0)
> The problem with this is that it requires any includes to be in $ROOT rather
> than /. This is okay when the include files have been bundled with a run-time
> library but not when they are in a package on their own - such as with the
> x11-proto packages.

My impression is that this is a case of broken ebuild dependencies.  If a runtime library requires x11-proto header packages in order for packages to link against it, than the runtime library is supposed to have those header packages in RDEPEND. This issue has been discussed here:

http://thread.gmane.org/gmane.linux.gentoo.devel/32318

[Comment 2 James Le Cuirot 2006-07-16 11:43:27 UTC]

If you agree with that argument then yes. spyderous evidently didn't agree with it and since he was the main man behind modular X, I guess it didn't happen that way in this case.

[Comment 3 Zac Medico 2006-07-16 11:55:28 UTC]

The bottom line is that a new dependecy type is needed in order to express dependencies that are needed to build against RDEPEND dependencies.  Perhaps RBDEPEND is a good name (runtime build dependency).  Under the system that is currently supported, there is no way to distiguish RDEPEND from RBDEPEND, so the only safe (and correct) way to specify RBDEPEND is to lump it together with RDEPEND.  To add a new dependency type would affect the whole developer community and would need to be proposed as a GLEP.