[patch]: dllwrap ported for x64 and support for new --[no-]leading-underscore option

Kai Tietz ktietz70@googlemail.com
Thu Nov 5 09:57:00 GMT 2009


2009/11/4 Dave Korn <dave.korn.cygwin@googlemail.com>:
> 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.  ]

Well, thanks. Only question remaining for me here is, shouldn't we
pass in dllwrap, if not already specified as argument, the
corresponding --machine option to dlltool, too?

>> 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

Ok, applied.

Cheers,
Kai

-- 
|  (\_/) This is Bunny. Copy and paste
| (='.'=) Bunny into your signature to help
| (")_(") him gain world domination



More information about the Binutils mailing list