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


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


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