[MinGW-Notify] [mingw] #41070: Please include libgccjit with MinGW GCC distribution

Back to archive index
MinGW Notification List mingw****@lists*****
Sat Jan 30 07:29:28 JST 2021


#41070: Please include libgccjit with MinGW GCC distribution

  Open Date: 2020-12-23 17:28
Last Update: 2021-01-29 22:29

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-29 22:29 Updated by: keith

Comment:

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.

---------------------------------------------------------------------
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



More information about the MinGW-Notify mailing list
Back to archive index