This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [patch, configures] Unify AC_SYS_LARGEFILE exception across dirs


On Thu, 05 Nov 2009 00:34:26 +0100, Joseph S. Myers wrote:
> On Thu, 5 Nov 2009, Jan Kratochvil wrote:
> 
> > Included for libgfortran/ as it uses libiberty/ to make it compatible.
> > Currently there is probably no AC_SYS_LARGEFILE-dependent type in its API,
> > though.
> 
> Target libraries had better not have their ABIs depend on 
> AC_SYS_LARGEFILE; they should be usable by user programs independent of 
> whether those programs use the large files ABI themselves.

Checked now the libgfortran ABI really uses parameters independent of
AC_SYS_LARGEFILE as you said:
	_gfortran_stat_i4 (gfc_array_i4 *)
	_gfortran_stat_i8 (gfc_array_i8 *)

So AC_SYS_LARGEFILE can be used in libgfortran/ always with no exceptions.
As libgfortran is using the stat() syscalls AC_SYS_LARGEFILE does make sense
there (and it is already present there).  So no change is needed there.


> (And how does it use libiberty?  Target libraries' use of libiberty should 
> be restricted to those parts with a GPL or LGPL runtime exception, and I 
> don't actually see any libiberty use in libgfortran.)

You are right it does not... I was grepping it but made some mistake, sorry.


Also checked what everything is really being affected by AC_SYS_LARGEFILE:
	http://www.unix.org/version2/whatsnew/lfs20mar.html#3.1.2
so
	egrep -r '\<(blkcnt_t|fsblkcnt_t|fsfilcnt_t|fpos_t|ino_t|off_t|rlim_t|dirent|flock|rlimit|stat|statvfs|F_GETLK|F_SETLK|F_SETLKW|RLIM_INFINITY|RLIM_SAVED_MAX|RLIM_SAVED_CUR)\>' include/
says only
	include/plugin-api.h:  off_t offset;
	include/plugin-api.h:  off_t filesize;
	->
		struct ld_plugin_input_file
		ld_plugin_claim_file_handler
		ld_plugin_get_input_file
therefore:

libgfortran/ really has no ABI incompatibility possibility.

libiberty/ really has no ABI incompatibility possibility.

lto-plugin/ has the ABI compatibility dependency.

gcc/ contains no AC_SYS_LARGEFILE - also when I needed >2GB .o 32bit file
I had to use x86_64 gcc with -m32.  But this is unrelated to this mail.

As there are currently no real ABI issue for the libiberty/ interface and I do
not understand well now the lto-plugin, gold and gcc dependencies while it is
completely unrelated to a regression in GDB I have reduced my request to:


Please include only the config/ part which is required for bfd/ and all its
ABI-dependent directories.  But none of such directories is in GCC SVN.



Thanks,
Jan


config/
2009-11-04  Jan Kratochvil  <jan.kratochvil@redhat.com>

	* largefile.m4: New file.

--- config/largefile.m4	(revision 0)
+++ config/largefile.m4	(revision 0)
@@ -0,0 +1,27 @@
+# This macro wraps AC_SYS_LARGEFILE with one exception keeping the decision
+# compatible across the sourceware subdirectories.
+
+AC_DEFUN([ACX_LARGEFILE],[dnl
+case "${target}" in
+changequote(,)dnl
+  sparc-*-solaris*|i[3-7]86-*-solaris*)
+changequote([,])dnl
+    # On native 32bit sparc and ia32 solaris, large-file and procfs support
+    # are mutually exclusive; and without procfs support, the elf module
+    # cannot provide certain routines such as elfcore_write_prpsinfo
+    # or elfcore_write_prstatus.  So unless the user explicitly requested
+    # large-file support through the --enable-largefile switch, disable
+    # large-file support in favor of procfs support.
+    # PR 9992/binutils: We have to duplicate the behaviour of bfd's
+    # configure script so that all the directories agree on the size of
+    # structures used to describe files.
+    if test "${target}" = "${host}" -a "$enable_largefile" != 'yes'; then
+      if test "$plugins" = "no"; then
+        enable_largefile="no"
+      fi
+    fi
+    ;;
+esac
+
+AC_SYS_LARGEFILE
+])


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]