This is the mail archive of the crossgcc@sources.redhat.com mailing list for the crossgcc project.

See the CrossGCC FAQ for lots more information.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Cross-compilers _without_ copying all of include & lib


%% "Kai Ruottu" <kai_ruottu@mbnet.fi> writes:

  kr> Ok, you maybe didn't mean just the symlinking but what on earth is
  kr> so hard in it?

  >> It turns out that the gcc build _DOES_ install some compiler-
  >> specific things, like linker scripts, into the lib directory:

  kr> You mean the 'make install'?

Yes.  You asked why it was so hard to do symlinks from the
compiler-specific directory to the real info, then delete them later.
One reason this is tricky is because the "make install" step will put
its own data there, which means sorting out which things should be there
because they're part of the compiler install, and which things should be
removed after the fact.

  kr> Just never use the '--with-headers=' and '--with-libs' again!

  >> So, how does one tell the cross-compiler build where to find the
  >> target headers and libraries, without using those flags?

  kr> The GCC manual has traditionally expected people knowing the 'ftp'
  kr> (get the GCC sources and the target stuff from the target system
  kr> into some temporary directory), 'cp' (to copy stuff between
  kr> directories) etc.  So being capable to copy the target libraries
  kr> and headers to be seen below the $prefix/$target install root, has
  kr> been expected.

I am certainly _capable_ of copying these things.  My entire point is
that I don't _WANT_ to copy these things... and I theoretically
shouldn't have to, because they're always available where they are
during the creation of the cross-compiler.

I want the cross-compiler to find them there, not use its own copy.

  kr> So you should use the symlinks that the headers and libraries are
  kr> only 'seen' there in '$prefix/$target/...', the symlinks will
  kr> point to their real places.

Again, not good enough: the compiler installs things into those
directories so they can't be symlinks pointing into the target space (I
don't want any mixing at all: the cross compiler stuff needs to stay on
one side of the fence and the target system stuff needs to stay on the
other side of the fence).

  kr> By opinion is that the extra libraries, libiberty, libstdc++,
  kr> libffi,... whatever there are, belong to the specific
  kr> target/GCC-version, not only to the specific target!

That's obviously not valid, because I don't have to rebuild my entire
system every time I get a new compiler, just like I don't have to
rebuild my compiler every time I install a new runtime library.

There is an argument to be made that the compiler and glibc are more
closely intertwined, but in fact no _native_ compiler enforces that
joining: people update glibc without updating GCC and vice versa all the
time.  And, there's definitely no reason to tie all the libraries in
/usr/lib to the GCC version.


Yes, of course, occasionally you do need to rebuild many or all things,
such as when switching from GCC 2.x to 3.x perhaps.  But these are very
rare occurrences indeed and we shouldn't make this painful situation the
norm.

IMO anyway :).

-- 
-------------------------------------------------------------------------------
 Paul D. Smith <psmith@nortelnetworks.com>   HASMAT--HA Software Mthds & Tools
 "Please remain calm...I may be mad, but I am a professional." --Mad Scientist
-------------------------------------------------------------------------------
   These are my opinions---Nortel Networks takes no responsibility for them.

------
Want more information?  See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
Want to unsubscribe? Send a note to crossgcc-unsubscribe@sources.redhat.com


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]