* Re: [ANNOUNCEMENT] Updated: binutils-2.34+1git.de9c1b7cfe-1 (x86/x86_64)
@ 2020-03-19 0:25 Steven Penny
2020-03-19 5:25 ` Marco Atzeri
2020-04-01 11:33 ` Jan Nijtmans
0 siblings, 2 replies; 14+ messages in thread
From: Steven Penny @ 2020-03-19 0:25 UTC (permalink / raw)
To: cygwin; +Cc: 10walls, yselkowitz
> 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
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [ANNOUNCEMENT] Updated: binutils-2.34+1git.de9c1b7cfe-1 (x86/x86_64)
2020-03-19 0:25 [ANNOUNCEMENT] Updated: binutils-2.34+1git.de9c1b7cfe-1 (x86/x86_64) Steven Penny
@ 2020-03-19 5:25 ` Marco Atzeri
2020-03-19 23:18 ` Brian Inglis
2020-04-01 11:33 ` Jan Nijtmans
1 sibling, 1 reply; 14+ messages in thread
From: Marco Atzeri @ 2020-03-19 5:25 UTC (permalink / raw)
To: cygwin
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
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [ANNOUNCEMENT] Updated: binutils-2.34+1git.de9c1b7cfe-1 (x86/x86_64)
2020-03-19 5:25 ` Marco Atzeri
@ 2020-03-19 23:18 ` Brian Inglis
2020-03-20 19:24 ` Hans-Bernhard Bröker
0 siblings, 1 reply; 14+ messages in thread
From: Brian Inglis @ 2020-03-19 23:18 UTC (permalink / raw)
To: cygwin
[-- Attachment #1: Type: text/plain, Size: 4169 bytes --]
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.
[-- Attachment #2: binutils-2.29-2.34-x86.log --]
[-- Type: text/plain, Size: 2971 bytes --]
2.29 2.34 Incr
7MB 48MB 40MB usr/lib/libbfd.a
1MB 34MB 33MB usr/lib/libopcodes.a
1MB 1MB usr/lib/libctf.a
1MB 1MB usr/lib/libctf-nobfd.a
1MB 1MB -85KB usr/lib/libiberty.a
10MB 87MB 77MB usr/lib/
1MB 15MB 14MB usr/bin/objdump.exe
1MB 9MB 7MB usr/bin/ld.bfd.exe
1MB 5MB 4MB usr/bin/as.exe
1MB 5MB 4MB usr/bin/windres.exe
1MB 5MB 4MB usr/bin/objcopy.exe
1MB 5MB 4MB usr/bin/strip.exe
1018KB 5MB 4MB usr/bin/gprof.exe
1002KB 5MB 4MB usr/bin/dlltool.exe
5MB 5MB usr/bin/sysdump.exe
5MB 5MB usr/bin/srconv.exe
974KB 5MB 4MB usr/bin/ar.exe
974KB 5MB 4MB usr/bin/ranlib.exe
973KB 5MB 4MB usr/bin/windmc.exe
959KB 5MB 4MB usr/bin/nm.exe
5MB 5MB usr/bin/coffdump.exe
949KB 5MB 4MB usr/bin/size.exe
948KB 5MB 4MB usr/bin/strings.exe
948KB 5MB 4MB usr/bin/addr2line.exe
944KB 5MB 4MB usr/bin/c++filt.exe
550KB 714KB 164KB usr/bin/readelf.exe
67KB 46KB -22KB usr/bin/dllwrap.exe
57KB 37KB -20KB usr/bin/elfedit.exe
18MB 118MB 100MB usr/bin/
253KB 249KB -4KB usr/include/bfd.h
... [22 files]
432KB 484KB 49KB usr/include/
533KB 546KB 13KB usr/share/doc/binutils/
604KB 626KB 21KB usr/share/info/
... [109 files]
9MB 12MB 2MB usr/share/locale/*/LC_MESSAGES/
... [19 files]
158KB 166KB 8KB usr/share/man/man1/
8KB 9KB 1KB usr/i686-pc-cygwin/lib/ldscripts/i386pe.x
8KB 9KB 1KB usr/i686-pc-cygwin/lib/ldscripts/i386pe.xa
9KB 9KB usr/i686-pc-cygwin/lib/ldscripts/i386pe.xe
8KB 9KB 1KB usr/i686-pc-cygwin/lib/ldscripts/i386pe.xbn
8KB 9KB 1KB usr/i686-pc-cygwin/lib/ldscripts/i386pe.xn
4KB 5KB 1KB usr/i686-pc-cygwin/lib/ldscripts/i386pe.xu
3KB 3KB -47 usr/i686-pc-cygwin/lib/ldscripts/i386pe.xr
9KB 9KB usr/i686-pc-cygwin/lib/ldscripts/i386pep.x
9KB 9KB usr/i686-pc-cygwin/lib/ldscripts/i386pep.xa
9KB 9KB usr/i686-pc-cygwin/lib/ldscripts/i386pep.xe
9KB 9KB usr/i686-pc-cygwin/lib/ldscripts/i386pep.xbn
9KB 9KB usr/i686-pc-cygwin/lib/ldscripts/i386pep.xn
5KB 5KB usr/i686-pc-cygwin/lib/ldscripts/i386pep.xu
3KB 3KB usr/i686-pc-cygwin/lib/ldscripts/i386pep.xr
9KB 9KB usr/i686-pc-cygwin/lib/ldscripts/i386pe_posix.x
9KB 9KB usr/i686-pc-cygwin/lib/ldscripts/i386pe_posix.xa
9KB 9KB usr/i686-pc-cygwin/lib/ldscripts/i386pe_posix.xe
9KB 9KB usr/i686-pc-cygwin/lib/ldscripts/i386pe_posix.xbn
9KB 9KB usr/i686-pc-cygwin/lib/ldscripts/i386pe_posix.xn
5KB 5KB usr/i686-pc-cygwin/lib/ldscripts/i386pe_posix.xu
3KB 3KB usr/i686-pc-cygwin/lib/ldscripts/i386pe_posix.xr
8KB 8KB usr/i686-pc-cygwin/lib/ldscripts/aarch64cloudabi.x
... [4442 files]
631 631 usr/i686-pc-cygwin/lib/ldscripts/z8002.xu
40KB 35MB 35MB usr/i686-pc-cygwin/lib/ldscripts/
40MB 255MB 215MB TOTAL
[-- Attachment #3: binutils-2.29-2.34-x86_64.log --]
[-- Type: text/plain, Size: 3008 bytes --]
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/
253KB 249KB -4KB usr/include/bfd.h
... [22 files]
432KB 484KB 51KB usr/include/
533KB 546KB 13KB usr/share/doc/binutils/
604KB 626KB 21KB usr/share/info/
... [109 files]
9MB 12MB 2MB usr/share/locale/*/LC_MESSAGES/
... [18 files]
3KB -3KB usr/share/man/man1/nlmconv.1.gz
158KB 166KB 8KB usr/share/man/man1/
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
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [ANNOUNCEMENT] Updated: binutils-2.34+1git.de9c1b7cfe-1 (x86/x86_64)
2020-03-19 23:18 ` Brian Inglis
@ 2020-03-20 19:24 ` Hans-Bernhard Bröker
2020-03-21 4:55 ` Marco Atzeri
0 siblings, 1 reply; 14+ messages in thread
From: Hans-Bernhard Bröker @ 2020-03-20 19:24 UTC (permalink / raw)
To: cygwin
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.
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [ANNOUNCEMENT] Updated: binutils-2.34+1git.de9c1b7cfe-1 (x86/x86_64)
2020-03-20 19:24 ` Hans-Bernhard Bröker
@ 2020-03-21 4:55 ` Marco Atzeri
2020-03-21 6:40 ` Marco Atzeri
0 siblings, 1 reply; 14+ messages in thread
From: Marco Atzeri @ 2020-03-21 4:55 UTC (permalink / raw)
To: cygwin
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
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [ANNOUNCEMENT] Updated: binutils-2.34+1git.de9c1b7cfe-1 (x86/x86_64)
2020-03-21 4:55 ` Marco Atzeri
@ 2020-03-21 6:40 ` Marco Atzeri
2020-03-22 20:19 ` Yaakov Selkowitz
0 siblings, 1 reply; 14+ messages in thread
From: Marco Atzeri @ 2020-03-21 6:40 UTC (permalink / raw)
To: cygwin
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
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [ANNOUNCEMENT] Updated: binutils-2.34+1git.de9c1b7cfe-1 (x86/x86_64)
2020-03-21 6:40 ` Marco Atzeri
@ 2020-03-22 20:19 ` Yaakov Selkowitz
2020-03-22 23:05 ` Marco Atzeri
0 siblings, 1 reply; 14+ messages in thread
From: Yaakov Selkowitz @ 2020-03-22 20:19 UTC (permalink / raw)
To: cygwin
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
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [ANNOUNCEMENT] Updated: binutils-2.34+1git.de9c1b7cfe-1 (x86/x86_64)
2020-03-22 20:19 ` Yaakov Selkowitz
@ 2020-03-22 23:05 ` Marco Atzeri
0 siblings, 0 replies; 14+ messages in thread
From: Marco Atzeri @ 2020-03-22 23:05 UTC (permalink / raw)
To: cygwin
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
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [ANNOUNCEMENT] Updated: binutils-2.34+1git.de9c1b7cfe-1 (x86/x86_64)
2020-03-19 0:25 [ANNOUNCEMENT] Updated: binutils-2.34+1git.de9c1b7cfe-1 (x86/x86_64) Steven Penny
2020-03-19 5:25 ` Marco Atzeri
@ 2020-04-01 11:33 ` Jan Nijtmans
2020-04-06 10:07 ` Problem in mingw64-i686-binutils [Was: Updated: binutils-2.34+1git.de9c1b7cfe-1 (x86/x86_64)] Jan Nijtmans
1 sibling, 1 reply; 14+ messages in thread
From: Jan Nijtmans @ 2020-04-01 11:33 UTC (permalink / raw)
To: 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.
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
^ permalink raw reply [flat|nested] 14+ messages in thread
* Problem in mingw64-i686-binutils [Was: Updated: binutils-2.34+1git.de9c1b7cfe-1 (x86/x86_64)]
2020-04-01 11:33 ` Jan Nijtmans
@ 2020-04-06 10:07 ` Jan Nijtmans
2020-04-06 23:55 ` JonY
0 siblings, 1 reply; 14+ messages in thread
From: Jan Nijtmans @ 2020-04-06 10:07 UTC (permalink / raw)
To: cygwin
Ping.
Would it be possible to release a version of mingw64-i686-binutils with the
same patch as done for binutils-2.34+1git.de9c1b7cfe-1? I suspect
this would resolve the problem described here.
Thanks!
Jan Nijtmans
Op wo 1 apr. 2020 om 13:33 schreef Jan Nijtmans <jan.nijtmans@gmail.com>:
>
> > 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
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Problem in mingw64-i686-binutils [Was: Updated: binutils-2.34+1git.de9c1b7cfe-1 (x86/x86_64)]
2020-04-06 10:07 ` Problem in mingw64-i686-binutils [Was: Updated: binutils-2.34+1git.de9c1b7cfe-1 (x86/x86_64)] Jan Nijtmans
@ 2020-04-06 23:55 ` JonY
2020-04-07 0:57 ` Yaakov Selkowitz
0 siblings, 1 reply; 14+ messages in thread
From: JonY @ 2020-04-06 23:55 UTC (permalink / raw)
To: Jan Nijtmans, cygwin
[-- Attachment #1.1: Type: text/plain, Size: 447 bytes --]
On 4/6/20 10:07 AM, Jan Nijtmans via Cygwin wrote:
> Ping.
>
> Would it be possible to release a version of mingw64-i686-binutils with the
> same patch as done for binutils-2.34+1git.de9c1b7cfe-1? I suspect
> this would resolve the problem described here.
>
> Thanks!
> Jan Nijtmans
Can you please report this issue to the binutils mailing list? I am
unfamiliar with the binutils internals to know what exactly went wrong.
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Problem in mingw64-i686-binutils [Was: Updated: binutils-2.34+1git.de9c1b7cfe-1 (x86/x86_64)]
2020-04-06 23:55 ` JonY
@ 2020-04-07 0:57 ` Yaakov Selkowitz
2020-04-07 10:29 ` JonY
0 siblings, 1 reply; 14+ messages in thread
From: Yaakov Selkowitz @ 2020-04-07 0:57 UTC (permalink / raw)
To: cygwin
On Mon, 2020-04-06 at 23:55 +0000, JonY via Cygwin wrote:
> On 4/6/20 10:07 AM, Jan Nijtmans via Cygwin wrote:
> > Ping.
> >
> > Would it be possible to release a version of mingw64-i686-binutils with the
> > same patch as done for binutils-2.34+1git.de9c1b7cfe-1? I suspect
> > this would resolve the problem described here.
>
> Can you please report this issue to the binutils mailing list? I am
> unfamiliar with the binutils internals to know what exactly went wrong.
JonY,
I think the relevant differences after 2.34 were PR24511 and PR25447,
which are already fixed upstream:
https://sourceware.org/git/?p=binutils-gdb.git;a=commitdiff;h=40bfb9762747f8336b17c70a0173d10200fa62eb
https://sourceware.org/git/?p=binutils-gdb.git;a=commitdiff;h=82f439d028c65663a0baf0a17ef5c4a2ea5c84a7
Adding those as patches to 2.34 should fix the issue without having to
resort to a git snapshot.
--
Yaakov
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Problem in mingw64-i686-binutils [Was: Updated: binutils-2.34+1git.de9c1b7cfe-1 (x86/x86_64)]
2020-04-07 0:57 ` Yaakov Selkowitz
@ 2020-04-07 10:29 ` JonY
0 siblings, 0 replies; 14+ messages in thread
From: JonY @ 2020-04-07 10:29 UTC (permalink / raw)
To: cygwin
[-- Attachment #1.1: Type: text/plain, Size: 1054 bytes --]
On 4/7/20 12:57 AM, Yaakov Selkowitz wrote:
> On Mon, 2020-04-06 at 23:55 +0000, JonY via Cygwin wrote:
>> On 4/6/20 10:07 AM, Jan Nijtmans via Cygwin wrote:
>>> Ping.
>>>
>>> Would it be possible to release a version of mingw64-i686-binutils with the
>>> same patch as done for binutils-2.34+1git.de9c1b7cfe-1? I suspect
>>> this would resolve the problem described here.
>>
>> Can you please report this issue to the binutils mailing list? I am
>> unfamiliar with the binutils internals to know what exactly went wrong.
>
> JonY,
>
> I think the relevant differences after 2.34 were PR24511 and PR25447,
> which are already fixed upstream:
>
> https://sourceware.org/git/?p=binutils-gdb.git;a=commitdiff;h=40bfb9762747f8336b17c70a0173d10200fa62eb
> https://sourceware.org/git/?p=binutils-gdb.git;a=commitdiff;h=82f439d028c65663a0baf0a17ef5c4a2ea5c84a7
>
> Adding those as patches to 2.34 should fix the issue without having to
> resort to a git snapshot.
>
OK, I'll see about using those 2 patches over the weekends.
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 14+ messages in thread
* [ANNOUNCEMENT] Updated: binutils-2.34+1git.de9c1b7cfe-1 (x86/x86_64)
@ 2020-03-15 10:33 JonY via Cygwin-announce
0 siblings, 0 replies; 14+ messages in thread
From: JonY via Cygwin-announce @ 2020-03-15 10:33 UTC (permalink / raw)
To: cygwin
[-- Attachment #1.1: Type: text/plain, Size: 749 bytes --]
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.
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 14+ messages in thread
end of thread, other threads:[~2020-04-07 10:30 UTC | newest]
Thread overview: 14+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-03-19 0:25 [ANNOUNCEMENT] Updated: binutils-2.34+1git.de9c1b7cfe-1 (x86/x86_64) Steven Penny
2020-03-19 5:25 ` Marco Atzeri
2020-03-19 23:18 ` Brian Inglis
2020-03-20 19:24 ` Hans-Bernhard Bröker
2020-03-21 4:55 ` Marco Atzeri
2020-03-21 6:40 ` Marco Atzeri
2020-03-22 20:19 ` Yaakov Selkowitz
2020-03-22 23:05 ` Marco Atzeri
2020-04-01 11:33 ` Jan Nijtmans
2020-04-06 10:07 ` Problem in mingw64-i686-binutils [Was: Updated: binutils-2.34+1git.de9c1b7cfe-1 (x86/x86_64)] Jan Nijtmans
2020-04-06 23:55 ` JonY
2020-04-07 0:57 ` Yaakov Selkowitz
2020-04-07 10:29 ` JonY
-- strict thread matches above, loose matches on Subject: below --
2020-03-15 10:33 [ANNOUNCEMENT] Updated: binutils-2.34+1git.de9c1b7cfe-1 (x86/x86_64) JonY via Cygwin-announce
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).