> > > usr/i386-pc-solaris2.11 > > > > Is this strange path necessary? Can't the > > subdirectories (bin and lib) go directly to /usr? > > The binutils configuration step creates this path by > default based on > the setting of the install path. It is a direct > result of moving > binutils from /usr/sfw/bin to /usr/bin. > > The commands in /usr/i386-pc-solaris2.11/bin conflict > with existing > Solaris commands in /usr/bin so moving the contents > directly to /usr is > not a good option.
However, the commands in this /usr/i386-pc-solaris2.11/bin are all already present in /usr/gnu/bin, and their g-prefixed versions are in /usr/bin, so I am wondering whether we could simply get rid of the directory. (if it has any real use, then please keep it) > The binutils configure command does support fine > tuning of install > locations. We can move /usr/i386-pc-solaris2.11 to > /usr/lib/i386-pc-solaris2.11, the same location used > by GCC 4.3.2. Indeed, or even directly /usr/lib/ldscripts. (Note that for gcc, there is /gcc/ between /usr/lib and i386-pc-solaris2.11, so we may not want to sneak binutils in there) > usr/lib/gcc/i386-pc-solaris2.11/4.3.2/include-fixed > > Do you really want to ship these as part of a gcc > > package? It means every time one of the packages that > > ships the original version of one of these headers > > changes, you will need to upgrade the gcc package as > > well. One could imagine a post-install type of script > > that is run for any header any package installs, and > > run for all headers when gcc is upgraded, but that is > > a pain. In linux, the list of fixed headers that is > > shipped is usually quite minimal and includes only > > system headers, not firefox, postgresql or > > evolution... > > Since the fixed headers are part of the standard GCC > build, I think it > makes sense to keep them. Ok, but do you have any plan on how to keep them in sync with the non-fixed headers? (By the way, I noticed the i386-pc-solaris2.11 triplet. Can opensolaris run on anything older than a 486? Probably "not this case", but still something that should be tackled some time, as 386 code has significant drawbacks) Thank you for having answered my email. -- This message posted from opensolaris.org
