-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Guys,
A recent bug report:
https://sourceforge.net/p/mingw/bugs/2326/prompted me to revisit an idea I've been toying with for a while -- as
it grows bigger, there may be mileage in offering a dynamic linking
option for libmingwex.a. However, when I try to create a DLL, I see:
$ mingw32-gcc -shared -o libmingwex-0.dll -Wl,--whole-archive \
libmingwex.a -Wl,--no-whole-archive -L.
./libmsvcrt.a(dgrcbs00324.o):(.text+0x0): multiple definition
of `_fpreset'
./libmingw32.a(CRT_fp10.o):.../mingwrt/CRT_fp10.c:14: first
defined here
collect2: error: ld returned 1 exit status
The problem here is Danny Smith's stratagem for overriding the default
behaviour of MSVCRT.DLL's _fpreset() function, by shoving an alternative
function of the same name, but with somewhat different behaviour, (which
he implements in CRT_fp10.c), into libmingw32.a, whence it should be
statically linked ahead of -lmsvcrt; he then also provided a further
free-standing implementation, CRT_fp8.c, which attempts to redirect the
call back to the (*_imp__fpreset)() entry point in MSVCRT.DLL.
Am I over-thinking this? Or is this as fragile as it appears? Was
Danny off his game, when he wrote this stuff? I guess it can't be too
serious a problem, since no issues have been reported in the 15 years
or so since Danny wrote it, but I can see the following possibilities:
1) User creates his own DLL, into which CRT_fp10.o is linked, and its
_fpreset() symbol is re-exported; that now provides its own copy of
(*_imp__fpreset)(), which neutralizes Danny's stratagem for calling
the MSVCRT.DLL implementation.
2) User creates his own DLL, within which _fpreset() is called; user
then links this DLL to his main program, which he also links with
CRT_fp8.o; calls to _fpreset() in his DLL will still be resolved
to whichever of CRT_fp10.o or CRT_fp8.o was linked into the DLL
itself, ignoring the intent of linking the main program with
CRT_fp8.o
Given that _fpreset() is strictly a Microsoft concept, conforming to no
known standard, I'd prefer to do away with this ambiguity, and leave it
to MSVCRT.DLL to resolve all references -- users who value standards,
and portability, should be using ISO-C99's fesetenv() function anyway.
Consequently, I've extensively revised Danny's implementation; would
anyone care to review the attached patch, before I commit it?
Of course, if the modified fesetenv() function continues to be linked
statically, from libmingwex.a, the potential for (non-deterministic)
behavioural ambiguity remains, spanning user created DLLs; that could
be mitigated by furnishing libmingwex-0.dll as an alternative to a
statically linked libmingwex.a, so that only a single fesetenv() need
exist within the process address space.
One final related issue: Danny's implementations of both CRT_fp10.c
and CRT_fp8.c defined fpreset(), (without leading underscore), as an
alias for each of his _fpreset() replacement implementations. Given
the complete lack of any defining standard, that seems kind of pointless
to me. Right now I've marked this as deprecated, but have retained a
__LIBIMPL__ stub for it, (reimplemented in terms of fesetenv()), but
it's messy, and I'd just as soon see it disappear altogether.
Any thoughts?
- --
Regards,
Keith.
Public key available from keys.gnupg.net
Key fingerprint: C19E C018 1547 DE50 E1D4 8F53 C0AD 36C6 347E 5A3F
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.20 (GNU/Linux)
iQIcBAEBAgAGBQJYm5v3AAoJEMCtNsY0flo/kMoP/0hMLVflTgbCBHDGxGSUByND
rLZzeA/lD+X2mlB4yNGGVI+VUGFEAbkt20oQYVT9vJiBAHB3+qAUoq3s1/+MJ1gw
9uUQMUKr5yrLTmi1nyR1gAR/zPnpzLwVoMVvVP46oV0skjf8+Ais11/kbHVyTSPy
B4e3WzJWka1f1WSKab+BU1iIzCksCf3OxwANWefHCNxvDBJlR30Hu9cDjbBkf4J5
0Cy4p99OuXQERzlcPplXQG79rrdeHGcH2q5insw8pDNG64Tm7Bbo9Th3JKblyuN+
BiOHHH0b3wPJ/tzJUJt84KBzeAvpv9+7ywzX8bu4Y7wnSneof9sBB/XpG9r8kwG1
+FJRPlHJ9KtMy5wFYka7/GWwmzyMf8vtUxz6awaf46IkPomQZvlLcAMOruvdUu+u
y7hkg4FnAgtGyfIxdQ20LTZjCZ3R5AkNrrpxaHpxU9OHe9TdFk79AL07Sbn+MCh7
iVVdZx+R79rxzbuX1nMJ/YKIYmsZnY1FAJMnmj+5bDzRrgkHf5zAPLYyPnLDJGIy
HHh7PDSrX0TewATDwtCYXB1xOlMKTIPsHjLdHXYla1uXq6syaj9UGn5N0NPh7qsr
RFGQ/thrhkEqWto5MzSEEu0YSlOkLMh6fzZGhLQu7Fy+LpOkZJXtiAHJFoJJrPKK
IwNh8PQbSoDJVLkR5AdT
=M8C7
-----END PGP SIGNATURE-----
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org!
http://sdm.link/slashdot_______________________________________________
MinGW-dvlpr mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mingw-dvlpr
Locked
fenv.patch (54K)