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: [patch]: dllwrap ported for x64 and support for new --[no-]leading-underscore option


Kai Tietz wrote:

>>  Not quite.  What is all this stuff about the "host"?  You appear to be
>> referring to the cpu type of the *target* by it, rather than any property of
>> the host machine, and of course I don't suppose you actually mean to imply
>> that the output should depend on properties of the system on which the
>> toolchain is running, rather than the properties of the system on which the
>> output executable images will be run.

> Well, I changed it. What me confused here is, that normally for
> configure --host is used as build target, and --target isn't necessary
> the same. So as this tool is a host tool, I was confused here.

  *All* tools are "host" tools, in the sense that they all *run on* the "host"
machine; that is what host means.

  It is only with generator tools, like the compiler and binutils, that there
arises a question of what machine the code they generate is targeted for -
hence anything to do with the output is a target matter.  When running native
binutils, the target is the same machine as the host, but not when running
cross binutils; and what we are discussing here is the cpu of the target
machine, on which the generated dll will run.

  Dllwrap can be run on a linux *host*, and will still generate a dll suitable
for an x86, x64 or Arm PE *target*.  (It can *only* be configured as a cross
tool on Linux, since it does not support Linux targets.)

[  This does occasionally result in the need for a switch of perspective, e.g.
when building a cross-compiler, you are making an executable that runs on the
host and emits output suitable for the target, but as part of that compiler
build you need to build target libraries, and when those target libraries are
configured, because they are applications that run on a platform and not
generators of any kind, they have only a host setting, and what was the target
for the compiler has to become the host for the target library, and the target
library does not have a target configure option!  But it's all perfectly
logical when you work it through, and generally only surprises people the
first time they realise it.  ]

> Here is the updated patch

  OK, with just ...

>        (main): Initialize which_host, pass new options
>        to dlltool, do underscoring dependent to
>        is_leading_underscore, and do '@12' decoration

  "do X dependent to Y" -> "do X dependent on Y".  Thanks!

    cheers,
      DaveK



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