[ANNOUNCEMENT] Updated: binutils-2.34+1git.de9c1b7cfe-1 (x86/x86_64)
Sun Mar 22 23:05:27 GMT 2020
Am 22.03.2020 um 21:19 schrieb Yaakov Selkowitz:
> On Sat, 2020-03-21 at 07:40 +0100, Marco Atzeri via Cygwin wrote:
>> Am 21.03.2020 um 05:55 schrieb Marco Atzeri:
>>> Am 20.03.2020 um 20:24 schrieb Hans-Bernhard Bröker:
>>>> Am 20.03.2020 um 00:18 schrieb Brian Inglis:
>>>>> On 2020-03-18 23:25, Marco Atzeri via Cygwin wrote:
>>>>>> It seems something is adding 5M or more to the normal
>>>>>> size of the programs
>>>>> See attached for summary details by arch, but main points for both
>>>>> are, on x86_64:
>>>> Could this be due to the ginormous number of targets configured into
>>>> the build?
>>> may be, as it also take ages to full compile with the
>>> current configuration:
>>> # --enable-shared
>>> I am testing a build dropping the "enable-targets=all"
>>> and also forcing the "enable-shared"
>>> --enable-shared \
> If that doesn't work, feel free to borrow:
thanks. It does not work.
> However, these libraries are (by design) API-unstable, so is not
> recommended to allow other code to link against these shared libs,
> therefore I would also suggest:
>>> Hoping it will note ages again....
>> "NOT take"
>> dropping the target seems to work very well
>> current version
>> $ du -sb /usr/bin/gprof.exe
>> 5424147 /usr/bin/gprof.exe
>> under build
>> $ du -sb gprof/gprof.exe
>> 19968 gprof/gprof.exe
in reality I was fooled by the stub,
the stripped version is ~ 1M insted of 5M
$ du -sb inst/usr/bin/gprof.exe
>> any clue why we are using a "enable-targets=all" options ?
> Not sure, but if it's just so that 32-bit utils can read 64-bit
> binaries (which is useful), --enable-targets=x86_64-pep should be
there is a trace of previous setting before "all" in the cygport
>> Any cross compiler should use its own binutils not the cygwin one, correct ?
> Yes, regardless.
Thanks as usual
More information about the Cygwin