[ANNOUNCEMENT] Updated: binutils-2.34+1git.de9c1b7cfe-1 (x86/x86_64)

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

[ANNOUNCEMENT] Updated: binutils-2.34+1git.de9c1b7cfe-1 (x86/x86_64)

cygwin-announce mailing list
The following packages have been uploaded to the Cygwin distribution:

* binutils-2.34+1git.de9c1b7cfe

This release should fix libtool shared library builds on 32bit Cygwin.


              *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO ***

If you want to unsubscribe from the cygwin-announce mailing list, look
at the "List-Unsubscribe: " tag in the email header of this message.
Send email to the address specified there. It will be in the format:

cygwin-announce-unsubscribe-you=yourdomain.com <at> cygwin.com

If you need more information on unsubscribing, start reading here:

http://sourceware.org/lists.html#unsubscribe-simple

Please read *all* of the information on unsubscribing that is available
starting at this URL.




--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [ANNOUNCEMENT] Updated: binutils-2.34+1git.de9c1b7cfe-1 (x86/x86_64)

Cygwin list mailing list
> The following packages have been uploaded to the Cygwin distribution:
>
> * binutils-2.34+1git.de9c1b7cfe
>
> This release should fix libtool shared library builds on 32bit Cygwin.

Below are the current "non Base" dependencies (and transitive dependencies) of
current "python3". As can be seen, "binutils" is now larger than all the other
dependencies combined.

Can we please, please address whatever exploded "binutils" size? Or perhaps once
and for all remove "binutils" as a dependency for "python3"? "binutils" is not
a runtime requirement for Python, only in the case where someone is utilizing
"ctypes", which one could argue is not a large enough percentage of users to
justify this.

25,016,180 binutils
     4,132 libcom_err2
    92,524 libcrypt2
    55,100 libexpat1
     3,964 libgdbm_compat4
    21,896 libgdbm6
   102,828 libgssapi_krb5_2
    73,344 libk5crypto3
   236,076 libkrb5_3
    14,424 libkrb5support0
    40,052 libnsl2
    19,432 libpkgconf3
   470,540 libsqlite3_0
    68,708 libtirpc3
     7,004 libtirpc-common
    16,848 libuuid-devel
    25,124 pkgconf
     5,972 pkg-config
       316 python3
 5,750,152 python36
 1,269,060 python-pip-wheel
   467,804 python-setuptools-wheel
--
Problem reports:      https://cygwin.com/problems.html
FAQ:                  https://cygwin.com/faq/
Documentation:        https://cygwin.com/docs.html
Unsubscribe info:     https://cygwin.com/ml/#unsubscribe-simple
Reply | Threaded
Open this post in threaded view
|

Re: [ANNOUNCEMENT] Updated: binutils-2.34+1git.de9c1b7cfe-1 (x86/x86_64)

Cygwin list mailing list
Am 19.03.2020 um 01:25 schrieb Steven Penny via Cygwin:

>> The following packages have been uploaded to the Cygwin distribution:
>>
>> * binutils-2.34+1git.de9c1b7cfe
>>
>> This release should fix libtool shared library builds on 32bit Cygwin.
>
> Below are the current "non Base" dependencies (and transitive dependencies) of
> current "python3". As can be seen, "binutils" is now larger than all the other
> dependencies combined.
>
> Can we please, please address whatever exploded "binutils" size?


It seems something is adding 5M or more to the normal
size of the programs


$ du -sh *.exe
5.2M    addr2line.exe
5.2M    ar.exe
5.8M    as.exe
5.2M    c++filt.exe
5.2M    coffdump.exe
5.2M    dlltool.exe
48K     dllwrap.exe
40K     elfedit.exe
5.2M    gprof.exe
8.9M    ld.bfd.exe
5.2M    nm.exe
5.3M    objcopy.exe
18M     objdump.exe
5.2M    ranlib.exe
740K    readelf.exe
5.2M    size.exe
5.2M    srconv.exe
5.2M    strings.exe
5.3M    strip.exe
5.2M    sysdump.exe
5.2M    windmc.exe
5.3M    windres.exe

and I will bet it is the same that pushed debian to have some shared lib

/usr/lib/x86_64-linux-gnu/libbfd-2.34-system.so
/usr/lib/x86_64-linux-gnu/libopcodes-2.34-system.so

to avoid data duplication between the binaries
https://packages.debian.org/sid/amd64/libbinutils/filelist






--
Problem reports:      https://cygwin.com/problems.html
FAQ:                  https://cygwin.com/faq/
Documentation:        https://cygwin.com/docs.html
Unsubscribe info:     https://cygwin.com/ml/#unsubscribe-simple
Reply | Threaded
Open this post in threaded view
|

Re: [ANNOUNCEMENT] Updated: binutils-2.34+1git.de9c1b7cfe-1 (x86/x86_64)

Brian Inglis
On 2020-03-18 23:25, Marco Atzeri via Cygwin wrote:

> Am 19.03.2020 um 01:25 schrieb Steven Penny via Cygwin:
>>> The following packages have been uploaded to the Cygwin distribution:
>>>
>>> * binutils-2.34+1git.de9c1b7cfe
>>>
>>> This release should fix libtool shared library builds on 32bit Cygwin.
>>
>> Below are the current "non Base" dependencies (and transitive dependencies) of
>> current "python3". As can be seen, "binutils" is now larger than all the other
>> dependencies combined.
>>
>> Can we please, please address whatever exploded "binutils" size?

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

 2.29  2.34  Incr
  9MB  53MB  43MB usr/lib/libbfd.a
  1MB  38MB  36MB usr/lib/libopcodes.a
        1MB   1MB usr/lib/libctf.a
        1MB   1MB usr/lib/libctf-nobfd.a
  1MB   1MB -85KB usr/lib/libiberty.a
 13MB  97MB  83MB usr/lib/

  2MB  17MB  15MB usr/bin/objdump.exe
  1MB   8MB   7MB usr/bin/ld.bfd.exe
  1MB   5MB   3MB usr/bin/as.exe
  1MB   5MB   3MB usr/bin/objcopy.exe
  1MB   5MB   3MB usr/bin/strip.exe
  1MB   5MB   4MB usr/bin/windres.exe
  1MB   5MB   4MB usr/bin/gprof.exe
  1MB   5MB   4MB usr/bin/dlltool.exe
        5MB   5MB usr/bin/sysdump.exe
        5MB   5MB usr/bin/srconv.exe
  1MB   5MB   4MB usr/bin/ar.exe
  1MB   5MB   4MB usr/bin/ranlib.exe
  1MB   5MB   4MB usr/bin/windmc.exe
  1MB   5MB   4MB usr/bin/nm.exe
        5MB   5MB usr/bin/coffdump.exe
  1MB   5MB   4MB usr/bin/strings.exe
  1MB   5MB   4MB usr/bin/size.exe
  1MB   5MB   4MB usr/bin/addr2line.exe
  1MB   5MB   4MB usr/bin/c++filt.exe
550KB 731KB 181KB usr/bin/readelf.exe
 44KB  46KB   1KB usr/bin/dllwrap.exe
 33KB  36KB   3KB usr/bin/elfedit.exe
 19MB 113MB  94MB usr/bin/

...

  8KB   9KB   1KB usr/x86_64-pc-cygwin/lib/ldscripts/i386pe.x
  8KB   9KB   1KB usr/x86_64-pc-cygwin/lib/ldscripts/i386pe.xa
  8KB   9KB   1KB usr/x86_64-pc-cygwin/lib/ldscripts/i386pe.xbn
        9KB   9KB usr/x86_64-pc-cygwin/lib/ldscripts/i386pe.xe
  8KB   9KB   1KB usr/x86_64-pc-cygwin/lib/ldscripts/i386pe.xn
  3KB   3KB   -47 usr/x86_64-pc-cygwin/lib/ldscripts/i386pe.xr
  4KB   5KB   1KB usr/x86_64-pc-cygwin/lib/ldscripts/i386pe.xu
  8KB   9KB   1KB usr/x86_64-pc-cygwin/lib/ldscripts/i386pep.x
  8KB   9KB   1KB usr/x86_64-pc-cygwin/lib/ldscripts/i386pep.xa
  8KB   9KB   1KB usr/x86_64-pc-cygwin/lib/ldscripts/i386pep.xbn
        9KB   9KB usr/x86_64-pc-cygwin/lib/ldscripts/i386pep.xe
  8KB   9KB   1KB usr/x86_64-pc-cygwin/lib/ldscripts/i386pep.xn
  4KB   3KB   -47 usr/x86_64-pc-cygwin/lib/ldscripts/i386pep.xr
  4KB   5KB   1KB usr/x86_64-pc-cygwin/lib/ldscripts/i386pep.xu
        9KB   9KB usr/x86_64-pc-cygwin/lib/ldscripts/i386pe_posix.x
        9KB   9KB usr/x86_64-pc-cygwin/lib/ldscripts/i386pe_posix.xa
        9KB   9KB usr/x86_64-pc-cygwin/lib/ldscripts/i386pe_posix.xbn
        9KB   9KB usr/x86_64-pc-cygwin/lib/ldscripts/i386pe_posix.xe
        9KB   9KB usr/x86_64-pc-cygwin/lib/ldscripts/i386pe_posix.xn
        3KB   3KB usr/x86_64-pc-cygwin/lib/ldscripts/i386pe_posix.xr
        5KB   5KB usr/x86_64-pc-cygwin/lib/ldscripts/i386pe_posix.xu
       13KB  13KB usr/x86_64-pc-cygwin/lib/ldscripts/arclinux_nps.x
... [4442 files]
         20    20 usr/x86_64-pc-cygwin/lib/ldscripts/vanilla.xr
 81KB  35MB  35MB usr/x86_64-pc-cygwin/lib/ldscripts/

 44MB 260MB 215MB TOTAL

The libraries jumping by 43MB and 36MB for an extra 83MB to nearly 100MB, the
exes from an average of about 1MB to over 5MB for an extra 94MB to over 110MB,
and the ldscripts by nearly 4500 more files for an extra 35MB, total increase
over 200MB to nearly 1/4GB is pretty huge.

> and I will bet it is the same that pushed debian to have some shared lib
>
> /usr/lib/x86_64-linux-gnu/libbfd-2.34-system.so
> /usr/lib/x86_64-linux-gnu/libopcodes-2.34-system.so
>
> to avoid data duplication between the binaries
> https://packages.debian.org/sid/amd64/libbinutils/filelist

--
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

This email may be disturbing to some readers as it contains
too much technical detail. Reader discretion is advised.

--
Problem reports:      https://cygwin.com/problems.html
FAQ:                  https://cygwin.com/faq/
Documentation:        https://cygwin.com/docs.html
Unsubscribe info:     https://cygwin.com/ml/#unsubscribe-simple

binutils-2.29-2.34-x86.log (3K) Download Attachment
binutils-2.29-2.34-x86_64.log (4K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [ANNOUNCEMENT] Updated: binutils-2.34+1git.de9c1b7cfe-1 (x86/x86_64)

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?

Asking the tools themselves about the list of targets they support,
compared to a run-off-the-mill default native build from current git
sources, yields:

> hbbro@NB5 ~/src/gnu/binutils/bld/gcc/binutils
> $ objdump -i | wc
>    8172   30919  441168
>
> hbbro@NB5 ~/src/gnu/binutils/bld/gcc/binutils
> $ ./objdump -i | wc
>     117     325    2831

That size difference evidently due to the 260+ supported output target
types in /usr/bin/objdump.exe, compared to 22 in my own build.

To put it another way the individual object files in libbfd.a are of
quite similar size; there just a whole lot more of them, and that
explains the difference.
--
Problem reports:      https://cygwin.com/problems.html
FAQ:                  https://cygwin.com/faq/
Documentation:        https://cygwin.com/docs.html
Unsubscribe info:     https://cygwin.com/ml/#unsubscribe-simple
Reply | Threaded
Open this post in threaded view
|

Re: [ANNOUNCEMENT] Updated: binutils-2.34+1git.de9c1b7cfe-1 (x86/x86_64)

Cygwin list mailing list
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
CYGCONF_ARGS="
         --enable-install-libiberty
         --disable-gdb
         --disable-libdecnumber
         --disable-readline
         --disable-sim
         --enable-64-bit-bfd
         --enable-targets=all
"

I am testing a build dropping the "enable-targets=all"
and also forcing the "enable-shared"

      --enable-shared \
         lt_cv_deplibs_check_method=pass_all


Hoping it will note ages again....

Marco



--
Problem reports:      https://cygwin.com/problems.html
FAQ:                  https://cygwin.com/faq/
Documentation:        https://cygwin.com/docs.html
Unsubscribe info:     https://cygwin.com/ml/#unsubscribe-simple
Reply | Threaded
Open this post in threaded view
|

Re: [ANNOUNCEMENT] Updated: binutils-2.34+1git.de9c1b7cfe-1 (x86/x86_64)

Cygwin list mailing list
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
> CYGCONF_ARGS="
>          --enable-install-libiberty
>          --disable-gdb
>          --disable-libdecnumber
>          --disable-readline
>          --disable-sim
>          --enable-64-bit-bfd
>          --enable-targets=all
> "
>
> I am testing a build dropping the "enable-targets=all"
> and also forcing the "enable-shared"
>
>       --enable-shared \
>          lt_cv_deplibs_check_method=pass_all
>
>
> Hoping it will note ages again....

"NOT take"


>
> Marco
>

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


Jon,
any clue why we are using a "enable-targets=all" options ?
Any cross compiler should use its own binutils not the cygwin one, correct ?

Marco




--
Problem reports:      https://cygwin.com/problems.html
FAQ:                  https://cygwin.com/faq/
Documentation:        https://cygwin.com/docs.html
Unsubscribe info:     https://cygwin.com/ml/#unsubscribe-simple
Reply | Threaded
Open this post in threaded view
|

Re: [ANNOUNCEMENT] Updated: binutils-2.34+1git.de9c1b7cfe-1 (x86/x86_64)

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
> > CYGCONF_ARGS="
> >          --enable-install-libiberty
> >          --disable-gdb
> >          --disable-libdecnumber
> >          --disable-readline
> >          --disable-sim
> >          --enable-64-bit-bfd
> >          --enable-targets=all
> > "
> >
> > I am testing a build dropping the "enable-targets=all"
> > and also forcing the "enable-shared"
> >
> >       --enable-shared \
> >          lt_cv_deplibs_check_method=pass_all

If that doesn't work, feel free to borrow:

https://github.com/cygwinports/binutils/blob/master/2.24.51-shared-libs.patch

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:

https://github.com/cygwinports/binutils/blob/master/binutils.cygport#L30-L38

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

> Any cross compiler should use its own binutils not the cygwin one, correct ?

Yes, regardless.

--
Yaakov


--
Problem reports:      https://cygwin.com/problems.html
FAQ:                  https://cygwin.com/faq/
Documentation:        https://cygwin.com/docs.html
Unsubscribe info:     https://cygwin.com/ml/#unsubscribe-simple
Reply | Threaded
Open this post in threaded view
|

Re: [ANNOUNCEMENT] Updated: binutils-2.34+1git.de9c1b7cfe-1 (x86/x86_64)

Cygwin list mailing list
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
>>> CYGCONF_ARGS="
>>>           --enable-install-libiberty
>>>           --disable-gdb
>>>           --disable-libdecnumber
>>>           --disable-readline
>>>           --disable-sim
>>>           --enable-64-bit-bfd
>>>           --enable-targets=all
>>> "
>>>
>>> I am testing a build dropping the "enable-targets=all"
>>> and also forcing the "enable-shared"
>>>
>>>        --enable-shared \
>>>           lt_cv_deplibs_check_method=pass_all
>
> If that doesn't work, feel free to borrow:

thanks. It does not work.

>
> https://github.com/cygwinports/binutils/blob/master/2.24.51-shared-libs.patch
>
> 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:
>
> https://github.com/cygwinports/binutils/blob/master/binutils.cygport#L30-L38

understood

>
>>> 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
1146387 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
> enough.

there is a trace of previous setting before "all" in the cygport

#
--enable-targets=i686-efi-pe,x86_64-efi-pe,ia64-efi-elf,x86_64-pc-cygwin,i686-pc-cygwin

>
>> Any cross compiler should use its own binutils not the cygwin one, correct ?
>
> Yes, regardless.
>
> --
> Yaakov
>

Thanks as usual
Marco
--
Problem reports:      https://cygwin.com/problems.html
FAQ:                  https://cygwin.com/faq/
Documentation:        https://cygwin.com/docs.html
Unsubscribe info:     https://cygwin.com/ml/#unsubscribe-simple
Reply | Threaded
Open this post in threaded view
|

Re: [ANNOUNCEMENT] Updated: binutils-2.34+1git.de9c1b7cfe-1 (x86/x86_64)

Cygwin list mailing list
In reply to this post by Cygwin list mailing list
> The following packages have been uploaded to the Cygwin distribution:
>
> * binutils-2.34+1git.de9c1b7cfe
>
> This release should fix libtool shared library builds on 32bit Cygwin.

When building latest Tcl/Tk 8.6.10 on Cygwin and Win32, I noted that
on mingw64-i686 the built executables crash immediately. Reverting
mingw64-i686-binutils from version 2.34-1 back to version
2.13.1.be46fa23-1 makes the build work again.

So, it looks like binutils for mingw64 (32-bit only) has the same
problem as the Cygwin-32 version.

Would it be possible to re-build mingw64-i686-binutils with
the same patch?

Regards,
    Jan Nijtmans
--
Problem reports:      https://cygwin.com/problems.html
FAQ:                  https://cygwin.com/faq/
Documentation:        https://cygwin.com/docs.html
Unsubscribe info:     https://cygwin.com/ml/#unsubscribe-simple