Send MinGW-Notify mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.osdn.me/mailman/listinfo/mingw-notify
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of MinGW-Notify digest..."
Please do not reply to this notification; the sender address is unable to
accept incoming e-mail. If you wish to unsubscribe you can do so at
https://lists.osdn.me/mailman/listinfo/mingw-notify.
Today's Topics:
1. [mingw] #41070: Please include libgccjit with MinGW GCC
distribution (MinGW Notification List)
2. [mingw] #41070: Please include libgccjit with MinGW GCC
distribution (MinGW Notification List)
----------------------------------------------------------------------
Message: 1
Date: Sat, 30 Jan 2021 09:10:30 +0200
From: MinGW Notification List <[email protected]>
To: OSDN Ticket System <[email protected]>
Subject: [MinGW-Notify] [mingw] #41070: Please include libgccjit with
MinGW GCC distribution
Message-ID: <[email protected]>
Content-Type: text/plain; charset=UTF-8
#41070: Please include libgccjit with MinGW GCC distribution
Open Date: 2020-12-23 19:28
Last Update: 2021-01-30 09:10
URL for this Ticket:
https://osdn.net//projects/mingw/ticket/41070
RSS feed for this Ticket:
https://osdn.net/ticket/ticket_rss.php?group_id=3917&tid=41070
---------------------------------------------------------------------
Last Changes/Comment on this Ticket:
2021-01-30 09:10 Updated by: eliz
Comment:
Reply To keith
Revisiting previous comment by keith
Reply To eliz
Why [does] libgccjit need to depend on libintl anyway? gcc.exe and cc1.exe,
for example, don't depend on it.
I'm puzzled, because [what I see here is that both gcc.exe and cc1.exe are
dynamically linked with libintl-8.dll (and also with libiconv-2.dll),
but] I do see that the version of gcc.exe in FRS is double the size of my
staged copy, and appears to be statically linked with both libiconv.a and
libintl.a,
rather than with libiconv.dll.a and libintl.dll.a. I think I know why, but I'd
like to review the issue; the DLL dependencies were intended.
This anomaly appears to result from a bug in GCC configuration scripts ...
possibly originating in autoconf macros provided by GNU gettext and GNU
libiconv respectively: if both libintl.dll.a and libintl.a are present, with
equal precedence in the linker search path, then GCC's configure will write
makefiles with libintl.a as the library reference, instead of -lintl (as it
should be); likewise for libiconv.a vs. -liconv, when libiconv.dll.a is also
present. This is just plain wrong ... it completely defeats the design
behaviour of the GNU linker, when building for a Windows target, which
stipulates that, in the presence of both libfoo.dll.a and libfoo.a, then -lfoo
maps to libfoo.dll.a, unless GCC's -static option is specified, or -lfoo is
resolved within the scope of the linker's -B static context; in either of these
latter cases, libfoo.dll.a is ignored, and -lfoo is mapped to libfoo.a.
Curiously, if libintl.a, and libiconv.a, are removed for the linker's search
path, leaving just libintl.dll.a, and libiconv.dll.a, then the GCC
configuration scripts write the makefile references correctly, as -lintl and
-liconv respectively.
To work around this GCC configuration bug, I have now removed libintl.a, and
libiconv.a, from the linker search path directory which is used by my mingw32
cross compiler, to ensure that the respective DLLs are linked, as I've always
intended. Prior to removal of these static libraries, the configuration bug was
causing inadvertent static linking, and some packages were unintentionally
published, with these libraries statically linked.
The dependency on libiconv and libintl DLLs might be okay for GCC, but there is
a larger problem here, related to those DLLs themselves. This is no longer
directly related to this ticket, so I will raise that issue on the MinGW
mailing list.
---------------------------------------------------------------------
Ticket Status:
Reporter: eliz
Owner: keith
Type: Feature Request
Status: Open [Owner assigned]
Priority: 5 - Medium
MileStone: (None)
Component: GCC
Severity: 5 - Medium
Resolution: None
---------------------------------------------------------------------
Ticket details:
ease add libgccjit to the binaries included in the MinGW GCC distributions.
This is required to be able to build projects that use libgccjit for JIT
compilation of code.
One example of this is "gccemacs", a branch of GNU Emacs development (soon to
land
on the master branch of Emacs) that compiles Emacs Lisp programs into native
x86 code
for faster runtime performance.
Thank you.
--
Ticket information of MinGW - Minimalist GNU for Windows project
MinGW - Minimalist GNU for Windows Project is hosted on OSDN
Project URL: https://osdn.net/projects/mingw/
OSDN: https://osdn.net
URL for this Ticket:
https://osdn.net/projects/mingw/ticket/41070
RSS feed for this Ticket:
https://osdn.net/ticket/ticket_rss.php?group_id=3917&tid=41070
------------------------------
Message: 2
Date: Sat, 30 Jan 2021 16:40:15 +0000
From: MinGW Notification List <[email protected]>
To: OSDN Ticket System <[email protected]>
Subject: [MinGW-Notify] [mingw] #41070: Please include libgccjit with
MinGW GCC distribution
Message-ID: <[email protected]>
Content-Type: text/plain; charset=UTF-8
#41070: Please include libgccjit with MinGW GCC distribution
Open Date: 2020-12-23 17:28
Last Update: 2021-01-30 16:40
URL for this Ticket:
https://osdn.net//projects/mingw/ticket/41070
RSS feed for this Ticket:
https://osdn.net/ticket/ticket_rss.php?group_id=3917&tid=41070
---------------------------------------------------------------------
Last Changes/Comment on this Ticket:
2021-01-30 16:40 Updated by: keith
Comment:
Reply To davidmalcolm
Looking at the patches themselves:
21-libgccjit-win32-fchmod.patch(1012bytes)
- Patch to correct for gratuitous misuse of fchmod()
This patch conflicts with
https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=c83027f32d9cca84959c7d6a1e519a0129731501
by Nicolas Bértolo which is on "master" for gcc 11, but not on the branches
for older releases.
Right. So, it wasn't in the GCC-9.2.0 tarball source, on which my patches are
(and for the purposes of an immediate MinGW release, must be) based.
Looking at it, I think he merely hacked out the call on Windows, ...
That's exactly what he did. I wasn't confident enough to do that — the
associated comment says:
/* Set the permissions of the copy to those of the original file,
in particular the "executable" bits. */
which doesn't give me enough confidence to dismiss bits, other than the
"executable" bits, as irrelevant. If it is exclusively the "executable" bits
which matter, (but the comment doesn't state this unambiguously), then the
fchmod() call does become irrelevant, on Windows, because there are no such
file attribute bits anyway.
which may lead to a run-time failure: on WIndows, is a DLL required to be
executable for it to be linkable into the process?
No. In fact, a DLL isn't usually executable anyway; it just happens to use the
same PE-coff encoding format as executables. In any case, "executability" on
Windows isn't established by any "bits", which can be manipulated by chmod(),
(much less fchmod(), which isn't available); it is determined, primarily, by
filename extension, and in some cases, this is augmented by a magic number
within the file. In the case of a DLL, the ".dll" extension identifies the
file as a probable shared library, and the magic number within it confirms that
it is in the PE-coff format, which is required to make it such.
I also wondered if there's a possible security issue here with closing the file
and changing its permissions by name, but the DLL is created within a tempdir
that only the user should have access to, with a random name.
I can't see how it would be any less secure than using fchmod() on the open
file, had that been possible. In any case, if it is only the "executable" bits
that matter, the whole issue becomes moot; the only bit on Windows, which
chmod() can realistically manipulate is the "write" bit (and there is only one
of them) — access permissions for different users, on Windows, are managed by
ACLs, (and other than on WinNT derivatives, not at all), rather than by the
limited set of file attribute bits
---------------------------------------------------------------------
Ticket Status:
Reporter: eliz
Owner: keith
Type: Feature Request
Status: Open [Owner assigned]
Priority: 5 - Medium
MileStone: (None)
Component: GCC
Severity: 5 - Medium
Resolution: None
---------------------------------------------------------------------
Ticket details:
ease add libgccjit to the binaries included in the MinGW GCC distributions.
This is required to be able to build projects that use libgccjit for JIT
compilation of code.
One example of this is "gccemacs", a branch of GNU Emacs development (soon to
land
on the master branch of Emacs) that compiles Emacs Lisp programs into native
x86 code
for faster runtime performance.
Thank you.
--
Ticket information of MinGW - Minimalist GNU for Windows project
MinGW - Minimalist GNU for Windows Project is hosted on OSDN
Project URL: https://osdn.net/projects/mingw/
OSDN: https://osdn.net
URL for this Ticket:
https://osdn.net/projects/mingw/ticket/41070
RSS feed for this Ticket:
https://osdn.net/ticket/ticket_rss.php?group_id=3917&tid=41070
------------------------------
Subject: Digest Footer
_______________________________________________
MinGW-Notify mailing list
[email protected]
https://lists.osdn.me/mailman/listinfo/mingw-notify
------------------------------
End of MinGW-Notify Digest, Vol 40, Issue 14
********************************************
