making compiletc more PPI compatable

[mikshaw]

Looking into compiletc.tce, it seems as though most of the files outside of /usr/local can simply be moved, since they are mostly bin, include, and lib files that should be just as easily accessible from /usr/local.  Moving these files would take practically the whole package out of RAM for those who use a PPI (persistent /usr/local) system.

/usr/share files are often hard-coded paths, so that's one thing that might not be easily moved.

/usr/i686-pc-linux-gnu/bin might be files that need that particular path, but I couldn't say

[Juanito]

The reason I built compiletc into /usr is that I noticed that there were far fewer errors compiling with a linux-from-scratch system in /usr than with compile-3.3.5 in dsl in /opt.

By adjusting the gcc specs file, I was able to get rid of many, but not all, of the errors with having compile-3.3.5 in /opt and thus I decided to build compiletc in /usr.

For sure you could argue that /opt is not the same as /usr/local, but I don't think just moving the files from /usr to /usr/local would work - there are several (many?) key files whose location is hard coded.

[mikshaw]

Seems strange to me that bin and lib files would be hardcoded.  Share often is hard-coded because, contrary to the name, these files are not typically shared between applications.  I'm not sure if there is an include path already set, as there is with bin and lib, but in any case it can be set with CFLAGS and similar.  Then again, maybe these dev files were intentionally made to not be overridden by external programs, but that seems a little strange for a Linux system.

I feel pretty confident that I could at least move the files from /bin, /lib, /usr/bin, and /usr/lib into /usr/local/{bin,lib} without problems, and repackage the remaining files into a much smaller archive.  If I break something I still have most of my TCE files to repopulate tclocal, so maybe I try that.

[softwaregurl]

this isn't actualy compiletc but it illustrates the point.

I just compiled a PERLmodule with perl_xml loaded.  It went to /usr/lib/... instead of /usr/local/lib/... because thats where perl_xml is.  I don't know if xml is needed for compiling or not.

the module is libmp3-info-perl.  Not terribly important, I can use it as is and most people wouldn't have much use for it but I was going to submit it.  I think it better to wait for now.

It crossed my mind...could the files be moved to some place special in /usr/local then the setup script or base system bind there.  mount --bind is pretty transparent, might fool the hard coded stuff.  If all modules are being moved soon anyway....just brainstorming.

[Juanito]

I just compiled a PERLmodule with perl_xml loaded.  It went to /usr/lib/... instead of /usr/local/lib/... because thats where perl_xml is.  I don't know if xml is needed for compiling or not.

The perl xml module is required for compiling some stuff (X for example), but the good thing is that there is usually a clear error message about it.

If you want to use perl normally - i.e. not for compiling - then you could use perl5 to build the modules and they would end up in /usr/local...

[mikshaw]

So far I've tried to build only one package (pcre) since splitting compiletc.tce into tclocal and a minimal tce (872K).
I encountered one library that was hard-coded in that situation: libc_nonshared.a, which worked fine after I symlinked it into /usr/lib