Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 140606 - Option to merge compile-time deps to $ROOT
Summary: Option to merge compile-time deps to $ROOT
Status: RESOLVED WORKSFORME
Alias: None
Product: Portage Development
Classification: Unclassified
Component: Conceptual/Abstract Ideas (show other bugs)
Hardware: All Linux
: High enhancement (vote)
Assignee: Portage team
URL:
Whiteboard:
Keywords:
Depends on: 174552
Blocks:
  Show dependency tree
 
Reported: 2006-07-16 02:45 UTC by James Le Cuirot
Modified: 2007-04-15 02:19 UTC (History)
1 user (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description James Le Cuirot gentoo-dev 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 gentoo-dev 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 gentoo-dev 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 gentoo-dev 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.