Re: [RFA] Add --with-libz-prefix option in config/zlib.m4
Hi! On Wed, 7 Jan 2015 17:00:59 +0100, Tristan Gingold wrote: > > > On 07 Jan 2015, at 15:45, Joel Brobecker wrote: > > This patch enhances config/zlib.m4 to introduce an extra option > > --with-libz-prefix which allows us to provide the location of > > the zlib library we want to use during the build. > > I prefer the gcc way to provide external library: > > --with-zlib -> system zlib used > --with-zlib=pathname -> zlib from pathname is used > > I have never needed different include and lib paths, but > this is supported by gcc. > > (Furthermore, I think that --with-zlib vs --with-libz-prefix is confusing). I'm not a GCC build machinery maintainer, but I do second Tristan's suggestion to stay compatible with the existing --with-[...] options that GCC already supports: > Cf: > > --with-gmp=pathname > --with-gmp-include=pathname > --with-gmp-lib=pathname > --with-mpfr=pathname > --with-mpfr-include=pathname > --with-mpfr-lib=pathname > --with-mpc=pathname > --with-mpc-include=pathname > --with-mpc-lib=pathname > If you want to build GCC but do not have the GMP library, the MPFR library > and/or the MPC library installed in a standard location and do not have their > sources present in the GCC source tree then you can explicitly specify the > directory where they are installed (‘--with-gmp=gmpinstalldir’, > ‘--with-mpfr=mpfrinstalldir’, ‘--with-mpc=mpcinstalldir’). The > --with-gmp=gmpinstalldir option is shorthand for > --with-gmp-lib=gmpinstalldir/lib and > --with-gmp-include=gmpinstalldir/include. Likewise the > --with-mpfr=mpfrinstalldir option is shorthand for > --with-mpfr-lib=mpfrinstalldir/lib and > --with-mpfr-include=mpfrinstalldir/include, also the --with-mpc=mpcinstalldir > option is shorthand for --with-mpc-lib=mpcinstalldir/lib and > --with-mpc-include=mpcinstalldir/include. If these shorthand assumptions are > not correct, you can use the explicit include and lib options directly. You > might also need to ensure the shared libraries can be found by the dynamic > linker when building and using GCC, for example by setting the runtime shared > library path variable (LD_LIBRARY_PATH on GNU/Linux and Solaris systems). > These flags are applicable to the host platform only. When building a cross > compiler, they will not be used to configure target libraries. Grüße, Thomas signature.asc Description: PGP signature
Re: [RFA] Add --with-libz-prefix option in config/zlib.m4
Hi! On Thu, 19 Feb 2015 08:54:46 +0100, I wrote: > On Wed, 7 Jan 2015 17:00:59 +0100, Tristan Gingold > wrote: > > > > > On 07 Jan 2015, at 15:45, Joel Brobecker wrote: > > > This patch enhances config/zlib.m4 to introduce an extra option > > > --with-libz-prefix which allows us to provide the location of > > > the zlib library we want to use during the build. > > > > I prefer the gcc way to provide external library: > > > > --with-zlib -> system zlib used > > --with-zlib=pathname -> zlib from pathname is used > > > > I have never needed different include and lib paths, but > > this is supported by gcc. > > > > (Furthermore, I think that --with-zlib vs --with-libz-prefix is confusing). > > I'm not a GCC build machinery maintainer, but I do second Tristan's > suggestion to stay compatible with the existing --with-[...] options that > GCC already supports: > > > Cf: > > > > --with-gmp=pathname > > --with-gmp-include=pathname > > --with-gmp-lib=pathname > > --with-mpfr=pathname > > --with-mpfr-include=pathname > > --with-mpfr-lib=pathname > > --with-mpc=pathname > > --with-mpc-include=pathname > > --with-mpc-lib=pathname > > If you want to build GCC but do not have the GMP library, the MPFR library > > and/or the MPC library installed in a standard location and do not have > > their sources present in the GCC source tree then you can explicitly > > specify the directory where they are installed (‘--with-gmp=gmpinstalldir’, > > ‘--with-mpfr=mpfrinstalldir’, ‘--with-mpc=mpcinstalldir’). The > > --with-gmp=gmpinstalldir option is shorthand for > > --with-gmp-lib=gmpinstalldir/lib and > > --with-gmp-include=gmpinstalldir/include. Likewise the > > --with-mpfr=mpfrinstalldir option is shorthand for > > --with-mpfr-lib=mpfrinstalldir/lib and > > --with-mpfr-include=mpfrinstalldir/include, also the > > --with-mpc=mpcinstalldir option is shorthand for > > --with-mpc-lib=mpcinstalldir/lib and > > --with-mpc-include=mpcinstalldir/include. If these shorthand assumptions > > are not correct, you can use the explicit include and lib options directly. > > You might also need to ensure the shared libraries can be found by the > > dynamic linker when building and using GCC, for example by setting the > > runtime shared library path variable (LD_LIBRARY_PATH on GNU/Linux and > > Solaris systems). > > These flags are applicable to the host platform only. When building a cross > > compiler, they will not be used to configure target libraries. Ah, now I've seen the other email: zlib is not actually used in GCC, and GCC and binutils/GDB have already diverged in their handling of such options -- unfortunately. Grüße, Thomas signature.asc Description: PGP signature
Re: [RFA] Add --with-libz-prefix option in config/zlib.m4
> On 07 Jan 2015, at 15:45, Joel Brobecker wrote: > > Hello, > > This patch enhances config/zlib.m4 to introduce an extra option > --with-libz-prefix which allows us to provide the location of > the zlib library we want to use during the build. I prefer the gcc way to provide external library: --with-zlib -> system zlib used --with-zlib=pathname -> zlib from pathname is used I have never needed different include and lib paths, but this is supported by gcc. (Furthermore, I think that --with-zlib vs --with-libz-prefix is confusing). Cf: --with-gmp=pathname --with-gmp-include=pathname --with-gmp-lib=pathname --with-mpfr=pathname --with-mpfr-include=pathname --with-mpfr-lib=pathname --with-mpc=pathname --with-mpc-include=pathname --with-mpc-lib=pathname If you want to build GCC but do not have the GMP library, the MPFR library and/or the MPC library installed in a standard location and do not have their sources present in the GCC source tree then you can explicitly specify the directory where they are installed (‘--with-gmp=gmpinstalldir’, ‘--with-mpfr=mpfrinstalldir’, ‘--with-mpc=mpcinstalldir’). The --with-gmp=gmpinstalldir option is shorthand for --with-gmp-lib=gmpinstalldir/lib and --with-gmp-include=gmpinstalldir/include. Likewise the --with-mpfr=mpfrinstalldir option is shorthand for --with-mpfr-lib=mpfrinstalldir/lib and --with-mpfr-include=mpfrinstalldir/include, also the --with-mpc=mpcinstalldir option is shorthand for --with-mpc-lib=mpcinstalldir/lib and --with-mpc-include=mpcinstalldir/include. If these shorthand assumptions are not correct, you can use the explicit include and lib options directly. You might also need to ensure the shared libraries can be found by the dynamic linker when building and using GCC, for example by setting the runtime shared library path variable (LD_LIBRARY_PATH on GNU/Linux and Solaris systems). These flags are applicable to the host platform only. When building a cross compiler, they will not be used to configure target libraries.
Re: [RFA] Add --with-libz-prefix option in config/zlib.m4
> > This patch enhances config/zlib.m4 to introduce an extra option > > --with-libz-prefix which allows us to provide the location of > > the zlib library we want to use during the build. > > I prefer the gcc way to provide external library: > > --with-zlib -> system zlib used > --with-zlib=pathname -> zlib from pathname is used Unfortunately, we took a different route with GDB (with-...-prefix). For instance: --with-libiconv-prefix --with-liblzma-prefix --with-libbabeltrace-prefix We already have a really nice macro that takes care of a lot of configury for us with respect to lib depenencies, which I see in gcc's root configure.ac that gmp/mpfr/mpc options is done via specific code. What I'm getting at is that, to achieve your prefered option (which I agree is more elegant), it would take a significant effort. -- Joel
Re: ping: [RFA] Add --with-libz-prefix option in config/zlib.m4
> On 21 Jan 2015, at 08:47, Joel Brobecker wrote: > > Thank you! :) What is the rational for having --with-zlib but --with-libz-prefix (ie zlib vs libz) ? Looks not very consistent. Tristan. > > On Wed, Jan 07, 2015 at 06:45:48PM +0400, Joel Brobecker wrote: >> Hello, >> >> This patch enhances config/zlib.m4 to introduce an extra option >> --with-libz-prefix which allows us to provide the location of >> the zlib library we want to use during the build. >> >> config/ChangeLog: >> >>* zlib.m4 (AM_ZLIB): Add --with-libz-prefix option support. >> >> I didn't see any file in the GCC project that uses this macro, >> so for the GCC repository, the change to zlib.m4 is it. But >> I am also attaching to this email a copy of the patch that >> will be applied to the binutils-gdb.git repository, with all >> configury using this macro being re-generated - mostly for info, >> also as a heads-up to both binutils and GDB. >> >> This was tested by regenerating all autoconf/automake files in >> the binutils-gdb project, and rebuilding GDB, using the following >> combinations: >> >> --with-zlib (system zlib used) >> --with-libz-prefix=/zlib/prefix (specific zlib linked in) >> --with-zlib --with-libz-prefix=/zlib/prefix (specific zlib linked in) >> >> --without-zlib (zlib support turned off) >> --without-zlib --with-zlib-prefix (zlib support turned off) >> >> --with-zlib (no system zlib available, configure fails with expected error) >> --with-zlib --with-libz-prefix=/invalid/zlib/prefix >> (no system zlib, configure fails with same error)
Re: ping: [RFA] Add --with-libz-prefix option in config/zlib.m4
> What is the rational for having --with-zlib but --with-libz-prefix > (ie zlib vs libz) ? Looks not very consistent. I agree it's unfortunate, but it is unavoidable if I want to keep the current option as it is (compatibility), and reuse AC_LIB_HAVE_LINKFLAGS (which is a fairly complex function). -- Joel
Re: ping #3: [RFA] Add --with-libz-prefix option in config/zlib.m4
On Wed, Feb 18, 2015 at 4:08 AM, Joel Brobecker wrote: > Yay? Nay? > > Thank you. > > On Wed, Jan 07, 2015 at 06:45:48PM +0400, Joel Brobecker wrote: >> Hello, >> >> This patch enhances config/zlib.m4 to introduce an extra option >> --with-libz-prefix which allows us to provide the location of >> the zlib library we want to use during the build. >> >> config/ChangeLog: >> >> * zlib.m4 (AM_ZLIB): Add --with-libz-prefix option support. >> >> I didn't see any file in the GCC project that uses this macro, >> so for the GCC repository, the change to zlib.m4 is it. But >> I am also attaching to this email a copy of the patch that >> will be applied to the binutils-gdb.git repository, with all >> configury using this macro being re-generated - mostly for info, >> also as a heads-up to both binutils and GDB. >> >> This was tested by regenerating all autoconf/automake files in >> the binutils-gdb project, and rebuilding GDB, using the following >> combinations: >> >> --with-zlib (system zlib used) >> --with-libz-prefix=/zlib/prefix (specific zlib linked in) >> --with-zlib --with-libz-prefix=/zlib/prefix (specific zlib linked in) >> >> --without-zlib (zlib support turned off) >> --without-zlib --with-zlib-prefix (zlib support turned off) >> >> --with-zlib (no system zlib available, configure fails with expected error) >> --with-zlib --with-libz-prefix=/invalid/zlib/prefix >> (no system zlib, configure fails with same error) >> >> OK to commit? Why do you want to turn off zlib? On Linux/x86, zlib is required for assembler. At least, you should issue an error when --without-libz is used in binutils for Linux/x86 target. I guess someone has asked it before. Why can't zlib be made the same as --with-mpc=PATH specify prefix directory for installed MPC package. Equivalent to --with-mpc-include=PATH/include plus --with-mpc-lib=PATH/lib --with-mpc-include=PATH specify directory for installed MPC include files --with-mpc-lib=PATH specify directory for the installed MPC library It is more flexible than your patch. If you have some existing packages which use your scheme, you can translate the configure command line options to this one. -- H.J.
Re: ping #3: [RFA] Add --with-libz-prefix option in config/zlib.m4
On 18 Feb 2015 04:56, H.J. Lu wrote: > On Wed, Feb 18, 2015 at 4:08 AM, Joel Brobecker wrote: > > On Wed, Jan 07, 2015 at 06:45:48PM +0400, Joel Brobecker wrote: > >> This patch enhances config/zlib.m4 to introduce an extra option > >> --with-libz-prefix which allows us to provide the location of > >> the zlib library we want to use during the build. > >> > >> config/ChangeLog: > >> > >> * zlib.m4 (AM_ZLIB): Add --with-libz-prefix option support. > >> > >> I didn't see any file in the GCC project that uses this macro, > >> so for the GCC repository, the change to zlib.m4 is it. But > >> I am also attaching to this email a copy of the patch that > >> will be applied to the binutils-gdb.git repository, with all > >> configury using this macro being re-generated - mostly for info, > >> also as a heads-up to both binutils and GDB. > >> > >> This was tested by regenerating all autoconf/automake files in > >> the binutils-gdb project, and rebuilding GDB, using the following > >> combinations: > >> > >> --with-zlib (system zlib used) > >> --with-libz-prefix=/zlib/prefix (specific zlib linked in) > >> --with-zlib --with-libz-prefix=/zlib/prefix (specific zlib linked in) > >> > >> --without-zlib (zlib support turned off) > >> --without-zlib --with-zlib-prefix (zlib support turned off) > >> > >> --with-zlib (no system zlib available, configure fails with expected > >> error) > >> --with-zlib --with-libz-prefix=/invalid/zlib/prefix > >> (no system zlib, configure fails with same error) > >> > >> OK to commit? > > Why do you want to turn off zlib? On Linux/x86, zlib is required > for assembler. At least, you should issue an error when --without-libz > is used in binutils for Linux/x86 target. err, when did that happen ? why would zlib be possibly required for an assembler ? -mike signature.asc Description: Digital signature
Re: ping #3: [RFA] Add --with-libz-prefix option in config/zlib.m4
On Wed, Feb 18, 2015 at 8:54 AM, Mike Frysinger wrote: > On 18 Feb 2015 04:56, H.J. Lu wrote: >> On Wed, Feb 18, 2015 at 4:08 AM, Joel Brobecker >> wrote: >> > On Wed, Jan 07, 2015 at 06:45:48PM +0400, Joel Brobecker wrote: >> >> This patch enhances config/zlib.m4 to introduce an extra option >> >> --with-libz-prefix which allows us to provide the location of >> >> the zlib library we want to use during the build. >> >> >> >> config/ChangeLog: >> >> >> >> * zlib.m4 (AM_ZLIB): Add --with-libz-prefix option support. >> >> >> >> I didn't see any file in the GCC project that uses this macro, >> >> so for the GCC repository, the change to zlib.m4 is it. But >> >> I am also attaching to this email a copy of the patch that >> >> will be applied to the binutils-gdb.git repository, with all >> >> configury using this macro being re-generated - mostly for info, >> >> also as a heads-up to both binutils and GDB. >> >> >> >> This was tested by regenerating all autoconf/automake files in >> >> the binutils-gdb project, and rebuilding GDB, using the following >> >> combinations: >> >> >> >> --with-zlib (system zlib used) >> >> --with-libz-prefix=/zlib/prefix (specific zlib linked in) >> >> --with-zlib --with-libz-prefix=/zlib/prefix (specific zlib linked in) >> >> >> >> --without-zlib (zlib support turned off) >> >> --without-zlib --with-zlib-prefix (zlib support turned off) >> >> >> >> --with-zlib (no system zlib available, configure fails with expected >> >> error) >> >> --with-zlib --with-libz-prefix=/invalid/zlib/prefix >> >> (no system zlib, configure fails with same error) >> >> >> >> OK to commit? >> >> Why do you want to turn off zlib? On Linux/x86, zlib is required >> for assembler. At least, you should issue an error when --without-libz >> is used in binutils for Linux/x86 target. > > err, when did that happen ? why would zlib be possibly required for an > assembler ? > -mike commit 89e7505fcde4bd83948f559f429a0e1eb4262f05 Author: H.J. Lu Date: Sun Dec 14 06:41:03 2014 -0800 Compress debug sections for Linux/x86 by default * config/tc-i386.c (flag_compress_debug): Default to compress debug sections for Linux. -- H.J.
Re: ping #3: [RFA] Add --with-libz-prefix option in config/zlib.m4
On 2/18/2015 10:54 AM, Mike Frysinger wrote: > On 18 Feb 2015 04:56, H.J. Lu wrote: >> On Wed, Feb 18, 2015 at 4:08 AM, Joel Brobecker >> wrote: >>> On Wed, Jan 07, 2015 at 06:45:48PM +0400, Joel Brobecker wrote: This patch enhances config/zlib.m4 to introduce an extra option --with-libz-prefix which allows us to provide the location of the zlib library we want to use during the build. config/ChangeLog: * zlib.m4 (AM_ZLIB): Add --with-libz-prefix option support. I didn't see any file in the GCC project that uses this macro, so for the GCC repository, the change to zlib.m4 is it. But I am also attaching to this email a copy of the patch that will be applied to the binutils-gdb.git repository, with all configury using this macro being re-generated - mostly for info, also as a heads-up to both binutils and GDB. This was tested by regenerating all autoconf/automake files in the binutils-gdb project, and rebuilding GDB, using the following combinations: --with-zlib (system zlib used) --with-libz-prefix=/zlib/prefix (specific zlib linked in) --with-zlib --with-libz-prefix=/zlib/prefix (specific zlib linked in) --without-zlib (zlib support turned off) --without-zlib --with-zlib-prefix (zlib support turned off) --with-zlib (no system zlib available, configure fails with expected error) --with-zlib --with-libz-prefix=/invalid/zlib/prefix (no system zlib, configure fails with same error) OK to commit? >> Why do you want to turn off zlib? On Linux/x86, zlib is required >> for assembler. At least, you should issue an error when --without-libz >> is used in binutils for Linux/x86 target. > err, when did that happen ? why would zlib be possibly required for an > assembler ? Is there going to be a configure error when the system does not have zlib and no argument is specified? This is a common issue for people building tools for RTEMS for the first time. > -mike -- Joel Sherrill, Ph.D. Director of Research & Development joel.sherr...@oarcorp.comOn-Line Applications Research Ask me about RTEMS: a free RTOS Huntsville AL 35805 Support Available(256) 722-9985
Re: ping #3: [RFA] Add --with-libz-prefix option in config/zlib.m4
On 18 Feb 2015 08:58, H.J. Lu wrote: > On Wed, Feb 18, 2015 at 8:54 AM, Mike Frysinger wrote: > > On 18 Feb 2015 04:56, H.J. Lu wrote: > >> On Wed, Feb 18, 2015 at 4:08 AM, Joel Brobecker wrote: > >> > On Wed, Jan 07, 2015 at 06:45:48PM +0400, Joel Brobecker wrote: > >> >> This patch enhances config/zlib.m4 to introduce an extra option > >> >> --with-libz-prefix which allows us to provide the location of > >> >> the zlib library we want to use during the build. > >> >> > >> >> config/ChangeLog: > >> >> > >> >> * zlib.m4 (AM_ZLIB): Add --with-libz-prefix option support. > >> >> > >> >> I didn't see any file in the GCC project that uses this macro, > >> >> so for the GCC repository, the change to zlib.m4 is it. But > >> >> I am also attaching to this email a copy of the patch that > >> >> will be applied to the binutils-gdb.git repository, with all > >> >> configury using this macro being re-generated - mostly for info, > >> >> also as a heads-up to both binutils and GDB. > >> >> > >> >> This was tested by regenerating all autoconf/automake files in > >> >> the binutils-gdb project, and rebuilding GDB, using the following > >> >> combinations: > >> >> > >> >> --with-zlib (system zlib used) > >> >> --with-libz-prefix=/zlib/prefix (specific zlib linked in) > >> >> --with-zlib --with-libz-prefix=/zlib/prefix (specific zlib linked in) > >> >> > >> >> --without-zlib (zlib support turned off) > >> >> --without-zlib --with-zlib-prefix (zlib support turned off) > >> >> > >> >> --with-zlib (no system zlib available, configure fails with expected > >> >> error) > >> >> --with-zlib --with-libz-prefix=/invalid/zlib/prefix > >> >> (no system zlib, configure fails with same error) > >> >> > >> >> OK to commit? > >> > >> Why do you want to turn off zlib? On Linux/x86, zlib is required > >> for assembler. At least, you should issue an error when --without-libz > >> is used in binutils for Linux/x86 target. > > > > err, when did that happen ? why would zlib be possibly required for an > > assembler ? > > commit 89e7505fcde4bd83948f559f429a0e1eb4262f05 > Author: H.J. Lu > Date: Sun Dec 14 06:41:03 2014 -0800 > > Compress debug sections for Linux/x86 by default > > * config/tc-i386.c (flag_compress_debug): Default to compress > debug sections for Linux. i don't see how that justifies making it a hard requirement -mike signature.asc Description: Digital signature
Re: ping #3: [RFA] Add --with-libz-prefix option in config/zlib.m4
On Wed, Feb 18, 2015 at 11:44 AM, Mike Frysinger wrote: > On 18 Feb 2015 08:58, H.J. Lu wrote: >> On Wed, Feb 18, 2015 at 8:54 AM, Mike Frysinger wrote: >> > On 18 Feb 2015 04:56, H.J. Lu wrote: >> >> On Wed, Feb 18, 2015 at 4:08 AM, Joel Brobecker wrote: >> >> > On Wed, Jan 07, 2015 at 06:45:48PM +0400, Joel Brobecker wrote: >> >> >> This patch enhances config/zlib.m4 to introduce an extra option >> >> >> --with-libz-prefix which allows us to provide the location of >> >> >> the zlib library we want to use during the build. >> >> >> >> >> >> config/ChangeLog: >> >> >> >> >> >> * zlib.m4 (AM_ZLIB): Add --with-libz-prefix option support. >> >> >> >> >> >> I didn't see any file in the GCC project that uses this macro, >> >> >> so for the GCC repository, the change to zlib.m4 is it. But >> >> >> I am also attaching to this email a copy of the patch that >> >> >> will be applied to the binutils-gdb.git repository, with all >> >> >> configury using this macro being re-generated - mostly for info, >> >> >> also as a heads-up to both binutils and GDB. >> >> >> >> >> >> This was tested by regenerating all autoconf/automake files in >> >> >> the binutils-gdb project, and rebuilding GDB, using the following >> >> >> combinations: >> >> >> >> >> >> --with-zlib (system zlib used) >> >> >> --with-libz-prefix=/zlib/prefix (specific zlib linked in) >> >> >> --with-zlib --with-libz-prefix=/zlib/prefix (specific zlib linked in) >> >> >> >> >> >> --without-zlib (zlib support turned off) >> >> >> --without-zlib --with-zlib-prefix (zlib support turned off) >> >> >> >> >> >> --with-zlib (no system zlib available, configure fails with expected >> >> >> error) >> >> >> --with-zlib --with-libz-prefix=/invalid/zlib/prefix >> >> >> (no system zlib, configure fails with same error) >> >> >> >> >> >> OK to commit? >> >> >> >> Why do you want to turn off zlib? On Linux/x86, zlib is required >> >> for assembler. At least, you should issue an error when --without-libz >> >> is used in binutils for Linux/x86 target. >> > >> > err, when did that happen ? why would zlib be possibly required for an >> > assembler ? >> >> commit 89e7505fcde4bd83948f559f429a0e1eb4262f05 >> Author: H.J. Lu >> Date: Sun Dec 14 06:41:03 2014 -0800 >> >> Compress debug sections for Linux/x86 by default >> >> * config/tc-i386.c (flag_compress_debug): Default to compress >> debug sections for Linux. > > i don't see how that justifies making it a hard requirement > -mike Can you elaborate? -- H.J.
Re: ping #3: [RFA] Add --with-libz-prefix option in config/zlib.m4
On Wed, 2015-02-18 at 11:52 -0800, H.J. Lu wrote: > On Wed, Feb 18, 2015 at 11:44 AM, Mike Frysinger wrote: > > On 18 Feb 2015 08:58, H.J. Lu wrote: > >> On Wed, Feb 18, 2015 at 8:54 AM, Mike Frysinger wrote: > >> >> Why do you want to turn off zlib? On Linux/x86, zlib is required > >> >> for assembler. At least, you should issue an error when --without-libz > >> >> is used in binutils for Linux/x86 target. > >> > > >> > err, when did that happen ? why would zlib be possibly required for an > >> > assembler ? > >> > >> commit 89e7505fcde4bd83948f559f429a0e1eb4262f05 > >> Author: H.J. Lu > >> Date: Sun Dec 14 06:41:03 2014 -0800 > >> > >> Compress debug sections for Linux/x86 by default > >> > >> * config/tc-i386.c (flag_compress_debug): Default to compress > >> debug sections for Linux. > > > > i don't see how that justifies making it a hard requirement > > Can you elaborate? That doesn't seem like a smart default. And why is is Linux/x86 only? Shouldn't that be something that is done explicitly by a distro configuring binutils after making sure it actually is beneficial (debuginfo is often compressed in a different way, on the package/file level or with dwz). And after making sure all tools actually work with it? There are various tools that don't handle the .zdebug format like valgrind. And at least elfutils has trouble with it for ET_REL files, like kernel modules, because relocations don't actually apply anymore to the section data as is (but only after the decompression). Cheers, Mark
Re: ping #3: [RFA] Add --with-libz-prefix option in config/zlib.m4
On Wed, Feb 18, 2015 at 09:32:21PM +0100, Mark Wielaard wrote: > > Can you elaborate? > > That doesn't seem like a smart default. And why is is Linux/x86 only? > Shouldn't that be something that is done explicitly by a distro > configuring binutils after making sure it actually is beneficial > (debuginfo is often compressed in a different way, on the package/file > level or with dwz). And after making sure all tools actually work with Yeah, dwz doesn't handle those, I think debugedit used by rpm doesn't either. When stripping into files, it would seem to be smarter to just compress the separate debug files rather than compressing individual sections anyway. Jakub
Re: ping #3: [RFA] Add --with-libz-prefix option in config/zlib.m4
On Wed, Feb 18, 2015 at 12:32 PM, Mark Wielaard wrote: > On Wed, 2015-02-18 at 11:52 -0800, H.J. Lu wrote: >> On Wed, Feb 18, 2015 at 11:44 AM, Mike Frysinger wrote: >> > On 18 Feb 2015 08:58, H.J. Lu wrote: >> >> On Wed, Feb 18, 2015 at 8:54 AM, Mike Frysinger wrote: >> >> >> Why do you want to turn off zlib? On Linux/x86, zlib is required >> >> >> for assembler. At least, you should issue an error when --without-libz >> >> >> is used in binutils for Linux/x86 target. >> >> > >> >> > err, when did that happen ? why would zlib be possibly required for an >> >> > assembler ? >> >> >> >> commit 89e7505fcde4bd83948f559f429a0e1eb4262f05 >> >> Author: H.J. Lu >> >> Date: Sun Dec 14 06:41:03 2014 -0800 >> >> >> >> Compress debug sections for Linux/x86 by default >> >> >> >> * config/tc-i386.c (flag_compress_debug): Default to compress >> >> debug sections for Linux. >> > >> > i don't see how that justifies making it a hard requirement >> >> Can you elaborate? > > That doesn't seem like a smart default. And why is is Linux/x86 only? > Shouldn't that be something that is done explicitly by a distro > configuring binutils after making sure it actually is beneficial > (debuginfo is often compressed in a different way, on the package/file > level or with dwz). And after making sure all tools actually work with > it? There are various tools that don't handle the .zdebug format like > valgrind. And at least elfutils has trouble with it for ET_REL files, > like kernel modules, because relocations don't actually apply anymore to > the section data as is (but only after the decompression). > Now it becomes a monthly topic: https://sourceware.org/ml/binutils/2015-01/msg00089.html -- H.J.
Re: ping #3: [RFA] Add --with-libz-prefix option in config/zlib.m4
On Wed, 2015-02-18 at 12:53 -0800, H.J. Lu wrote: > On Wed, Feb 18, 2015 at 12:32 PM, Mark Wielaard wrote: > > That doesn't seem like a smart default. And why is is Linux/x86 only? > > Shouldn't that be something that is done explicitly by a distro > > configuring binutils after making sure it actually is beneficial > > (debuginfo is often compressed in a different way, on the package/file > > level or with dwz). And after making sure all tools actually work with > > it? There are various tools that don't handle the .zdebug format like > > valgrind. And at least elfutils has trouble with it for ET_REL files, > > like kernel modules, because relocations don't actually apply anymore to > > the section data as is (but only after the decompression). > > Now it becomes a monthly topic: > > https://sourceware.org/ml/binutils/2015-01/msg00089.html Thanks, I hadn't seen that before. Alan Modra makes some good points in that thread why it is not a good change: https://sourceware.org/ml/binutils/2015-01/msg00135.html Do people agree with that? And/Or can the change be reverted for now till there is agreement it is a desirable default? Thanks, Mark
Re: ping #3: [RFA] Add --with-libz-prefix option in config/zlib.m4
On Wed, Feb 18, 2015 at 1:40 PM, Mark Wielaard wrote: > On Wed, 2015-02-18 at 12:53 -0800, H.J. Lu wrote: >> On Wed, Feb 18, 2015 at 12:32 PM, Mark Wielaard wrote: >> > That doesn't seem like a smart default. And why is is Linux/x86 only? >> > Shouldn't that be something that is done explicitly by a distro >> > configuring binutils after making sure it actually is beneficial >> > (debuginfo is often compressed in a different way, on the package/file >> > level or with dwz). And after making sure all tools actually work with >> > it? There are various tools that don't handle the .zdebug format like >> > valgrind. And at least elfutils has trouble with it for ET_REL files, >> > like kernel modules, because relocations don't actually apply anymore to >> > the section data as is (but only after the decompression). >> >> Now it becomes a monthly topic: >> >> https://sourceware.org/ml/binutils/2015-01/msg00089.html > > Thanks, I hadn't seen that before. Alan Modra makes some good points in > that thread why it is not a good change: > https://sourceware.org/ml/binutils/2015-01/msg00135.html > Do people agree with that? And/Or can the change be reverted for now > till there is agreement it is a desirable default? > It may not be a good idea for all targets. If you find an issue on Linux/x86, please file a bug binutils report. Thanks. -- H.J.
Re: ping #3: [RFA] Add --with-libz-prefix option in config/zlib.m4
On 18 Feb 2015 13:54, H.J. Lu wrote: > On Wed, Feb 18, 2015 at 1:40 PM, Mark Wielaard wrote: > > On Wed, 2015-02-18 at 12:53 -0800, H.J. Lu wrote: > >> On Wed, Feb 18, 2015 at 12:32 PM, Mark Wielaard wrote: > >> > That doesn't seem like a smart default. And why is is Linux/x86 only? > >> > Shouldn't that be something that is done explicitly by a distro > >> > configuring binutils after making sure it actually is beneficial > >> > (debuginfo is often compressed in a different way, on the package/file > >> > level or with dwz). And after making sure all tools actually work with > >> > it? There are various tools that don't handle the .zdebug format like > >> > valgrind. And at least elfutils has trouble with it for ET_REL files, > >> > like kernel modules, because relocations don't actually apply anymore to > >> > the section data as is (but only after the decompression). > >> > >> Now it becomes a monthly topic: > >> > >> https://sourceware.org/ml/binutils/2015-01/msg00089.html > > > > Thanks, I hadn't seen that before. Alan Modra makes some good points in > > that thread why it is not a good change: > > https://sourceware.org/ml/binutils/2015-01/msg00135.html > > Do people agree with that? And/Or can the change be reverted for now > > till there is agreement it is a desirable default? > > It may not be a good idea for all targets. If you find an issue > on Linux/x86, please file a bug binutils report. i think we already have the reports: multiple people don't think it should be (1) x86-specific or (2) required. don't get me wrong -- i think having support like this is great. that doesn't mean we should be forcing it. -mike signature.asc Description: Digital signature
Re: ping #3: [RFA] Add --with-libz-prefix option in config/zlib.m4
On Wed, Feb 18, 2015 at 2:21 PM, Mike Frysinger wrote: > On 18 Feb 2015 13:54, H.J. Lu wrote: >> On Wed, Feb 18, 2015 at 1:40 PM, Mark Wielaard wrote: >> > On Wed, 2015-02-18 at 12:53 -0800, H.J. Lu wrote: >> >> On Wed, Feb 18, 2015 at 12:32 PM, Mark Wielaard wrote: >> >> > That doesn't seem like a smart default. And why is is Linux/x86 only? >> >> > Shouldn't that be something that is done explicitly by a distro >> >> > configuring binutils after making sure it actually is beneficial >> >> > (debuginfo is often compressed in a different way, on the package/file >> >> > level or with dwz). And after making sure all tools actually work with >> >> > it? There are various tools that don't handle the .zdebug format like >> >> > valgrind. And at least elfutils has trouble with it for ET_REL files, >> >> > like kernel modules, because relocations don't actually apply anymore to >> >> > the section data as is (but only after the decompression). >> >> >> >> Now it becomes a monthly topic: >> >> >> >> https://sourceware.org/ml/binutils/2015-01/msg00089.html >> > >> > Thanks, I hadn't seen that before. Alan Modra makes some good points in >> > that thread why it is not a good change: >> > https://sourceware.org/ml/binutils/2015-01/msg00135.html >> > Do people agree with that? And/Or can the change be reverted for now >> > till there is agreement it is a desirable default? >> >> It may not be a good idea for all targets. If you find an issue >> on Linux/x86, please file a bug binutils report. > > i think we already have the reports: multiple people don't think it should be > (1) x86-specific or (2) required. don't get me wrong -- i think having > support > like this is great. that doesn't mean we should be forcing it. > -mike Please file a bug report with a testcase. -- H.J.
Re: ping #3: [RFA] Add --with-libz-prefix option in config/zlib.m4
On 18 Feb 2015 14:24, H.J. Lu wrote:
> On Wed, Feb 18, 2015 at 2:21 PM, Mike Frysinger wrote:
> > i think we already have the reports: multiple people don't think it should
> > be
> > (1) x86-specific or (2) required. don't get me wrong -- i think having
> > support
> > like this is great. that doesn't mean we should be forcing it.
>
> Please file a bug report with a testcase.
this is getting kafka-esque. you yourself stated:
On Linux/x86, zlib is required for assembler. At least, you should issue an
error when --without-libz is used in binutils for Linux/x86 target.
that should not be the case. making someone open a bug report so you can close
it with "fixed" and a patch is wasting time. just fix it now.
all that said, if we look at your actual commit (89e7505fcde4bd83948f559f429a0):
gas/config/tc-i386.c:
+#ifdef TE_LINUX
+/* Default to compress debug sections for Linux. */
+int flag_compress_debug = 1;
+#endif
and we look at where that flag is used:
gas/as.c:
...
case OPTION_COMPRESS_DEBUG:
#ifdef HAVE_ZLIB_H
flag_compress_debug = 1;
#else
as_warn (_("cannot compress debug sections (zlib not installed)"));
#endif /* HAVE_ZLIB_H */
break;
case OPTION_NOCOMPRESS_DEBUG:
flag_compress_debug = 0;
break;
...
gas/write.c:
void
write_object_file (void)
{
...
if (flag_compress_debug)
bfd_map_over_sections (stdoutput, compress_debug, (char *) 0);
...
static void
compress_debug (bfd *abfd, asection *sec, void *xxx ATTRIBUTE_UNUSED)
{
...
strm = compress_init ();
if (strm == NULL)
return;
it turns out the current code does *not* require zlib. as long as that does
not
change (either issuing a warning or throwing an error), i see no reason why we
need or should make zlib a requirement in binutils, regardless of target.
-mike
signature.asc
Description: Digital signature
Re: ping #3: [RFA] Add --with-libz-prefix option in config/zlib.m4
> Why do you want to turn off zlib? On Linux/x86, zlib is required > for assembler. At least, you should issue an error when --without-libz > is used in binutils for Linux/x86 target. I am trying to do the exact opposite, which is to provide an option to compile WITH zlib, but using an install at a non-standard location. > I guess someone has asked it before. Why can't zlib be made the > same as > > --with-mpc=PATH specify prefix directory for installed MPC package. > Equivalent to --with-mpc-include=PATH/include plus > --with-mpc-lib=PATH/lib > --with-mpc-include=PATH specify directory for installed MPC include files > --with-mpc-lib=PATH specify directory for the installed MPC library > > It is more flexible than your patch. If you have some existing packages > which use your scheme, you can translate the configure command line > options to this one. This is fustrating. I already answered that question. -- Joel
Re: ping #3: [RFA] Add --with-libz-prefix option in config/zlib.m4
On Wed, Feb 18, 2015 at 01:54:17PM -0800, H.J. Lu wrote: > On Wed, Feb 18, 2015 at 1:40 PM, Mark Wielaard wrote: > > On Wed, 2015-02-18 at 12:53 -0800, H.J. Lu wrote: > >> On Wed, Feb 18, 2015 at 12:32 PM, Mark Wielaard wrote: > >> > That doesn't seem like a smart default. And why is is Linux/x86 only? > >> > Shouldn't that be something that is done explicitly by a distro > >> > configuring binutils after making sure it actually is beneficial > >> > (debuginfo is often compressed in a different way, on the package/file > >> > level or with dwz). And after making sure all tools actually work with > >> > it? There are various tools that don't handle the .zdebug format like > >> > valgrind. And at least elfutils has trouble with it for ET_REL files, > >> > like kernel modules, because relocations don't actually apply anymore to > >> > the section data as is (but only after the decompression). > >> > >> Now it becomes a monthly topic: > >> > >> https://sourceware.org/ml/binutils/2015-01/msg00089.html > > > > Thanks, I hadn't seen that before. Alan Modra makes some good points in > > that thread why it is not a good change: > > https://sourceware.org/ml/binutils/2015-01/msg00135.html > > Do people agree with that? And/Or can the change be reverted for now > > till there is agreement it is a desirable default? > > > > It may not be a good idea for all targets. If you find an issue > on Linux/x86, please file a bug binutils report. The issue is that this is not something that is target architecture specific. As others have pointed out this isn't something that is target architecture-dependent. So please first get agreement on whether or not to default for the OS (or for all ELF targets or the GNU targets). Otherwise distros will have to revert on a target by target basis to get something consistent. Secondly the bug is not directly in binutils (but there might be an issue between versions compiled with/without zlib support). If .zdebug sections are left in on disk ET_REL files, like kernel modules, there is a problem for programs that don't deal with .zdebug sections (and/or relocations against them) in ET_REL files like elfutils, systemtap, debugedit, dwz, etc. Thanks, Mark
Re: ping #3: [RFA] Add --with-libz-prefix option in config/zlib.m4
On Wed, Feb 18, 2015 at 11:17 PM, Mark Wielaard wrote: > On Wed, Feb 18, 2015 at 01:54:17PM -0800, H.J. Lu wrote: >> On Wed, Feb 18, 2015 at 1:40 PM, Mark Wielaard wrote: >> > On Wed, 2015-02-18 at 12:53 -0800, H.J. Lu wrote: >> >> On Wed, Feb 18, 2015 at 12:32 PM, Mark Wielaard wrote: >> >> > That doesn't seem like a smart default. And why is is Linux/x86 only? >> >> > Shouldn't that be something that is done explicitly by a distro >> >> > configuring binutils after making sure it actually is beneficial >> >> > (debuginfo is often compressed in a different way, on the package/file >> >> > level or with dwz). And after making sure all tools actually work with >> >> > it? There are various tools that don't handle the .zdebug format like >> >> > valgrind. And at least elfutils has trouble with it for ET_REL files, >> >> > like kernel modules, because relocations don't actually apply anymore to >> >> > the section data as is (but only after the decompression). >> >> >> >> Now it becomes a monthly topic: >> >> >> >> https://sourceware.org/ml/binutils/2015-01/msg00089.html >> > >> > Thanks, I hadn't seen that before. Alan Modra makes some good points in >> > that thread why it is not a good change: >> > https://sourceware.org/ml/binutils/2015-01/msg00135.html >> > Do people agree with that? And/Or can the change be reverted for now >> > till there is agreement it is a desirable default? >> > >> >> It may not be a good idea for all targets. If you find an issue >> on Linux/x86, please file a bug binutils report. > > The issue is that this is not something that is target architecture > specific. As others have pointed out this isn't something that is > target architecture-dependent. So please first get agreement on whether > or not to default for the OS (or for all ELF targets or the GNU targets). As I said before, I don't think it will happen any time soon. > Otherwise distros will have to revert on a target by target basis to get > something consistent. Secondly the bug is not directly in binutils (but > there might be an issue between versions compiled with/without zlib > support). If .zdebug sections are left in on disk ET_REL files, like > kernel modules, there is a problem for programs that don't deal with Please stop spreading your FUD about kernel modules. If you find a problem with kernel modules, please open a binutils bug report. > .zdebug sections (and/or relocations against them) in ET_REL files > like elfutils, systemtap, debugedit, dwz, etc. I opened a bug against elfutils: https://bugzilla.redhat.com/show_bug.cgi?id=807053 It shouldn't be be too hard to fix. We fixed it in readelf. -- H.J.
Re: ping #3: [RFA] Add --with-libz-prefix option in config/zlib.m4
On Thu, Feb 19, 2015 at 05:52:26AM -0800, H.J. Lu wrote: > On Wed, Feb 18, 2015 at 11:17 PM, Mark Wielaard wrote: > >> >> Now it becomes a monthly topic: > >> >> > >> >> https://sourceware.org/ml/binutils/2015-01/msg00089.html > >> > > >> > Thanks, I hadn't seen that before. Alan Modra makes some good points in > >> > that thread why it is not a good change: > >> > https://sourceware.org/ml/binutils/2015-01/msg00135.html > >> > Do people agree with that? And/Or can the change be reverted for now > >> > till there is agreement it is a desirable default? > >> > > >> > >> It may not be a good idea for all targets. If you find an issue > >> on Linux/x86, please file a bug binutils report. > > > > The issue is that this is not something that is target architecture > > specific. As others have pointed out this isn't something that is > > target architecture-dependent. So please first get agreement on whether > > or not to default for the OS (or for all ELF targets or the GNU targets). > > As I said before, I don't think it will happen any time soon. You will have to convince a global maintainer or the other architecture maintainers this is a good default. > > Otherwise distros will have to revert on a target by target basis to get > > something consistent. Secondly the bug is not directly in binutils (but > > there might be an issue between versions compiled with/without zlib > > support). If .zdebug sections are left in on disk ET_REL files, like > > kernel modules, there is a problem for programs that don't deal with > > Please stop spreading your FUD about kernel modules. If you find a problem > with kernel modules, please open a binutils bug report. I think you misunderstand. Although a quick search indicates there are issues in binutils dealing with .zdebug sections (e.g. #11819 and #15989) I wasn't talking about binutils. Other utilities that might have problems with ET_REL files containing .zdebug sections. I know that is the case for kernel modules. But as you point out below there are other issues/bugs in tools dealing with .zdebug ET_REL files too. The point was that Alan mentions a couple of issues that I didn't see you address yet. You might run into difficulty with other tools or older binutils that deal with relocatable object files that are important to consider before making this the default. You might just want to reply to his message if you feel I am misrepresenting things: https://sourceware.org/ml/binutils/2015-01/msg00135.html > > .zdebug sections (and/or relocations against them) in ET_REL files > > like elfutils, systemtap, debugedit, dwz, etc. > > I opened a bug against elfutils: > > https://bugzilla.redhat.com/show_bug.cgi?id=807053 > > It shouldn't be be too hard to fix. Thanks. Patches welcome of course. It is slightly tricky because in elfutils the code that deals with .[z]debug DWARF data (libdw) is separate from the code that deals with loading of ELF data and applying relocations (libdwfl). The relocations are applied early by code that doesn't know about .zdebug compression and so relies on the section headers to know data offsets and sizes. The bug report has some hints how to maybe handle this. Cheers, Mark
