This is the mail archive of the binutils@sourceware.org mailing list for the binutils project.


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 toolchain vs. info files


Doug Evans wrote:
> Dave Korn writes:

>  >   When we build and install a cross binutils, $prefix/man gets a whole
>  load of > man pages all prefixed with the target - i.e.
>  > $prefix/man/man1/$target-{ar,as,ld,...}.
> 
> I wonder if it's the $target- prefix that's the bug.

  I think not.  Everything else gets $target-prefixed, so it's only the .info
files that are the odd one out.

>  >   OTOH, the info files installed to $prefix/info aren't prefixed with
>  the > target.
>  >
>  >   This means that 1) you can't look them up by "info
>  $target-$utilityname" (it > brings you the related manpage instead)
> 
> ... but if one has 5 targets why replicate the same document 5 times?

  Because they may all be very different versions, with different command-line
options.  (This applies to Gcc as well, which has more option-churn than
binutils, but the point is valid for both).  It is not the same document.
 
> It's been awhile, but I don't recall any target-specific elements
> in any particular man page or info doc.

  It's crawling with them.  Just take a look in /src/gas/doc at all the
c-*.texi files, for instance.

> what I'm refering to is, 
> of course, whether the docs get something extra or different iff that
> particular target is configured.]

  Yes, absolutely they do.  Check out all the "@ifset <CPUNAME>" directives in
as.texinfo.

> One could use hard links, I guess, if one is careful.  [And, for
> completeness' 
> sake, I'm obviously setting aside hosts that don't have hard links.]

  Yes, I could, but a) I don't know if that would be sufficient for them to be
found under the names b) the non-prefixed files that the links point to would
still override your system's toolchain info files.
 
>  > and 2) they may override (or be
>  > overridden by) the info files for your main system tools, which can be
>  a bit > of a snag if they are built from different binutils versions.
> 
> Question: Does binutils install any target-independent tools?  gprof?
> [it's been awhile, I forget.]
> I wonder if this is no different than downloading gcc 4.x and configuring
> it with --prefix=/usr and installing it on a linux distribution, for
> example, that ships with 3.x.

  Well, in a way it is; gcc suffers the exact same problem.  But in a far more
important way, it isn't.  If you build and install gcc 4.x on a gcc 3.x
system, you will indeed have two executables called gcc, and they may clash,
but since each one will also have installed an executable with the version
number as part of the name, you can still access them, by invoking either
gcc-3.3.6 or gcc-4.0.1 or whatever.

>  If you don't want to clobber your main system tools,
> don't configure with, for example, --prefix=/usr. [Assuming, of course,
> that 
> there is, or may at some future time be, target-independent tools in the
> release - One can define the problem away, by requiring every binary to
> have the $target- prefix, but I'm not sure the cure is better than the
> disease here.] 

  You're missing the point here.  I haven't clobbered my main system tools.
The build system is carefully set up so that cross tools can never clash with
system tools, and the main part of the way that is done is by prefixing the
names.  I don't see why the man/info pages should clash, since for different
targets and different versions they *are* different man/info pages.

> On a related subject, target libraries and includes go in
> $exec_prefix/$target. 
> I'm curious if there's any plan to change that to $prefix/$target?
> [I can't recall why $exec_prefix/$target was chosen (way back when).
> Anyone remember?  Maybe I'm overlooking something.]
> [linux hosted target libraries/includes shouldn't be any different than
> cygwin hosted target libraries/includes, for example]

  Heh, I really have no idea what the purpose of --exec-prefix is, and since
it defaults to being the same as --prefix, I don't ever bother setting it.

  Anyway, sounds like you're as at a loss as I am to understand why there's
this inconsistency.

    cheers,
      DaveK
-- 
Can't think of a witty .sigline today....



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