Hi Simon, > On 2020-07-28 9:51 a.m., Rainer Orth wrote: >> Unfortunately not: is sometimes used in code shared with >> non-Solaris systems, none of which have . So we'd have to >> conditionalize on HAVE_PROCFS_H vs. HAVE_SYS_PROCFS_H. >> >> And on older Solaris 11.3, even when using the new procfs interface, >> errors out when largefile support is enabled. >> >> As I said: it's a royal mess ;-( >> >> Rainer > > Ok, I see. > > The only part I'm not sure about is the part that adds --enable-gdb to all > configure > files. For example we now have this in bfd's configure: > > $ ./binutils/configure --help | grep gdb > --enable-gdb[=ARG] build gdb [ARG={yes,no}] > > I understand that you want to catch whether the user enabled or disabled > building GDB > with --enable-gdb or --disable-gdb, but the result is a bit weird. Is > there a way not > to include it in the --help? > > Ideally, the top-level configure system would be able to tell which modules > are enabled. > I don't know much about it, maybe there's a way. It's even simpler: every configure script has code to parse --enable-foo/--disable-foo and turn the result into enable_foo=[yes|no]. AC_ARG_ENABLE primarily adds default and additional values and properly aligned help text, none of which is needed in this case. So just removing the macro invocation still works. > In your patch, can > > : ${enable_largefile="no"} > > become just > > enable_largefile="no" > > ? No: the code has been (and should remain) like this. It allows the user to override the automatic largefile detection with explicit --enable-largefile/--disable-largefile options without having to change the code. I've now removed AC_ARG_ENABLE from largefile.m4. Retested on i386-pc-solaris2.11 without and with --disable-gdb, checking that _FILE_OFFSET_BITS are set as expected, and amd64-pc-solaris2.11. Ok for master now? Rainer -- ----------------------------------------------------------------------------- Rainer Orth, Center for Biotechnology, Bielefeld University