4
0
mirror of git://sourceware.org/git/newlib-cygwin.git synced 2025-02-21 00:07:36 +08:00
Corinna Vinschen 582628d551 Revert "Cygwin: Make sure newer apps get uname_x even when loading uname dynamically"
This reverts commit 532b91d24e9496c7988b2b1dda7fc0e8b161f782.

It turned out that this patch has undesired side effects.  To wit, if a
newer, post-uname_x executable was linked against or loading an older,
pre-uname_x DLL, and this DLL called uname.  This call would jump into
the old uname with the old struct utsname as parameter, but given the
newer executable it would get redirected to uname_x.  uname_x in turn
would overwrite stack memory it should leave well alone, given it
expects the newer, larger struct utsname.

For the entire discussion see the thread starting at
https://cygwin.com/pipermail/cygwin/2021-February/247870.html
and continuing in March at
https://cygwin.com/pipermail/cygwin/2021-March/247930.html
For a description where we're coming from, see
https://cygwin.com/pipermail/cygwin/2021-March/247959.html

While we *could* make the scenario in question work by patching dlsym,
the problem would actually be the same, just for dynamic loading.  In
the end, we're missing the information, which Cygwin version has been
used when building DLLs.

Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
2021-03-08 10:33:30 +01:00
2016-06-23 15:54:55 -04:00
2016-06-23 15:54:55 -04:00
2021-03-05 15:23:24 -05:00
2020-08-28 22:51:57 +01:00
2015-03-09 20:53:11 +01:00
2016-06-23 15:54:55 -04:00
2016-03-22 10:25:20 +01:00
2016-03-22 10:25:20 +01:00
2021-02-24 11:03:28 +01:00
2021-02-24 11:03:28 +01:00
2016-03-22 10:25:20 +01:00
2016-03-22 10:25:20 +01:00
2016-03-22 10:25:20 +01:00
2016-03-22 10:25:20 +01:00
2010-01-09 21:11:32 +00:00
2014-02-05 13:17:47 +00:00
2010-01-09 21:11:32 +00:00
2010-01-09 21:11:32 +00:00
2016-06-23 15:54:55 -04:00
2016-03-22 10:25:20 +01:00
2016-03-22 10:25:20 +01:00
2016-03-22 10:25:20 +01:00

		   README for GNU development tools

This directory contains various GNU compilers, assemblers, linkers, 
debuggers, etc., plus their support routines, definitions, and documentation.

If you are receiving this as part of a GDB release, see the file gdb/README.
If with a binutils release, see binutils/README;  if with a libg++ release,
see libg++/README, etc.  That'll give you info about this
package -- supported targets, how to use it, how to report bugs, etc.

It is now possible to automatically configure and build a variety of
tools with one command.  To build all of the tools contained herein,
run the ``configure'' script here, e.g.:

	./configure 
	make

To install them (by default in /usr/local/bin, /usr/local/lib, etc),
then do:
	make install

(If the configure script can't determine your type of computer, give it
the name as an argument, for instance ``./configure sun4''.  You can
use the script ``config.sub'' to test whether a name is recognized; if
it is, config.sub translates it to a triplet specifying CPU, vendor,
and OS.)

If you have more than one compiler on your system, it is often best to
explicitly set CC in the environment before running configure, and to
also set CC when running make.  For example (assuming sh/bash/ksh):

	CC=gcc ./configure
	make

A similar example using csh:

	setenv CC gcc
	./configure
	make

Much of the code and documentation enclosed is copyright by
the Free Software Foundation, Inc.  See the file COPYING or
COPYING.LIB in the various directories, for a description of the
GNU General Public License terms under which you can copy the files.

REPORTING BUGS: Again, see gdb/README, binutils/README, etc., for info
on where and how to report problems.
Description
No description provided
Readme 156 MiB
Languages
C 61.5%
Makefile 19.6%
C++ 10.4%
Assembly 4.9%
M4 1%
Other 2.4%