Re: [PATCH] libstdc++: use a link test to test for -Wl,-z,relro
On 9/22/20 8:50 AM, Jonathan Wakely wrote:
>
> I don't see a patch, or any previous email to the libstdc++ list.
>
> Please resend with the patch, CCing libstdc++@
>
> Thanks.
>
>
>
Resent for the record. I've been told it might not be appropriate
because some targets cannot link yet and therefore will fail incorrectly.
Currently, the linker support is misdetected since binutils can support
multiple targets. MinGW/Cygwin PE formats don't support such a flag.
From: Jonathan Yong <10wa...@gmail.com>
Date: Sun, 22 Mar 2020 01:59:37 + (+0800)
Subject: libstdc++: use a link test to test for -Wl,-z,relro
X-Git-Url:
https://repo.or.cz/gcc/cygwin-gcc.git/commitdiff_plain/1b20e03e7468760828bfc70fc5e811b5b3738adf
libstdc++: use a link test to test for -Wl,-z,relro
Do a link test instead of just a grep. The linker can
support multiple targets, but not all targets can use it.
Signed-off-by: Jonathan Yong <10wa...@gmail.com>
---
diff --git a/libstdc++-v3/acinclude.m4 b/libstdc++-v3/acinclude.m4
index bc7d137dc74..209aa3a91f3 100644
--- a/libstdc++-v3/acinclude.m4
+++ b/libstdc++-v3/acinclude.m4
@@ -274,7 +274,16 @@ AC_DEFUN([GLIBCXX_CHECK_LINKER_FEATURES], [
ac_ld_relro=no
if test x"$with_gnu_ld" = x"yes"; then
AC_MSG_CHECKING([for ld that supports -Wl,-z,relro])
-cxx_z_relo=`$LD -v --help 2>/dev/null | grep "z relro"`
+ac_save_ldflags="$LDFLAGS"
+LDFLAGS="$LDFLAGS -Wl,-z,relro"
+AC_LINK_IFELSE([
+ AC_LANG_SOURCE(
+[[int main() { return 0; }]]
+ )],
+ [cxx_z_relo="1"],
+ [cxx_z_relo=""])
+ LDFLAGS="$ac_save_ldflags"
+
if test -n "$cxx_z_relo"; then
OPT_LDFLAGS="-Wl,-z,relro"
ac_ld_relro=yes
signature.asc
Description: OpenPGP digital signature
Re: [PATCH] Cygwin/MinGW: Do not version lto plugins
On 9/21/20 11:38 AM, Martin Liška wrote: > Sorry, it's not caused by your patch. It's our SUSE-specific package setup. > How does liblto_plugin.so.0.0.0 get loaded? I find only mentions of liblto_plugin.so. Is Suse GCC patched to use the versioned library? signature.asc Description: OpenPGP digital signature
Re: [PATCH] gcc: Make strchr return value pointers const
On 9/17/20 3:56 AM, Jeff Law wrote: > > If it's been ack'd by a maintainer, yes. Jakub definitely qualifies as > a maintainer, so feel free to push it on Martin's behalf. > > > jeff Sure, it has been pushed, thanks all. signature.asc Description: OpenPGP digital signature
[PATCH] libstdc++: use lt_host_flags for libstdc++.la
For platforms like Mingw and Cygwin, cygwin refuses to generate the
shared library without using -no-undefined.
Attached patch makes sure the right flags are used, since libtool is
already used to link libstdc++.
Patch OK?
From 4ba039687182fccd67e1170f89e259e1c4a58eeb Mon Sep 17 00:00:00 2001
From: Jonathan Yong <10wa...@gmail.com>
Date: Sun, 22 Mar 2020 09:56:58 +0800
Subject: [PATCH 1/1] libstdc++: use lt_host_flags for libstdc++.la
Signed-off-by: Jonathan Yong <10wa...@gmail.com>
---
libstdc++-v3/src/Makefile.am | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libstdc++-v3/src/Makefile.am b/libstdc++-v3/src/Makefile.am
index a139adc81b3..498f533f3d3 100644
--- a/libstdc++-v3/src/Makefile.am
+++ b/libstdc++-v3/src/Makefile.am
@@ -107,7 +107,7 @@ libstdc___la_DEPENDENCIES = \
libstdc___la_LDFLAGS = \
-version-info $(libtool_VERSION) ${version_arg} -lm
-libstdc___la_LINK = $(CXXLINK) $(libstdc___la_LDFLAGS)
+libstdc___la_LINK = $(CXXLINK) $(libstdc___la_LDFLAGS) $(lt_host_flags)
# Use special rules for compatibility-ldbl.cc compilation, as we need to
# pass -mlong-double-64.
--
2.11.4.GIT
signature.asc
Description: OpenPGP digital signature
Re: [PATCH] libstdc++: use a link test to test for -Wl,-z,relro
On 9/13/20 3:37 PM, JonY wrote: > On 9/10/20 2:23 PM, JonY wrote: >> Do a link test instead of just a grep. The linker can >> support multiple targets, but not all targets can use it. >> >> Cygwin/MinGW ld can support ELF but the PE format for Windows itself >> does not support such a feature. Attached patch OK? >> >> I'm not confident with regenerating configure due to some unrelated >> changes added, can someone else help with that? >> > > Ping? > Ping 2? signature.asc Description: OpenPGP digital signature
Re: [PATCH] libstdc++: use a link test to test for -Wl,-z,relro
On 9/10/20 2:23 PM, JonY wrote: > Do a link test instead of just a grep. The linker can > support multiple targets, but not all targets can use it. > > Cygwin/MinGW ld can support ELF but the PE format for Windows itself > does not support such a feature. Attached patch OK? > > I'm not confident with regenerating configure due to some unrelated > changes added, can someone else help with that? > Ping? signature.asc Description: OpenPGP digital signature
[PATCH] libstdc++: use a link test to test for -Wl,-z,relro
Do a link test instead of just a grep. The linker can
support multiple targets, but not all targets can use it.
Cygwin/MinGW ld can support ELF but the PE format for Windows itself
does not support such a feature. Attached patch OK?
I'm not confident with regenerating configure due to some unrelated
changes added, can someone else help with that?
From: Jonathan Yong <10wa...@gmail.com>
Date: Sun, 22 Mar 2020 01:59:37 + (+0800)
Subject: libstdc++: use a link test to test for -Wl,-z,relro
X-Git-Url:
https://repo.or.cz/gcc/cygwin-gcc.git/commitdiff_plain/1b20e03e7468760828bfc70fc5e811b5b3738adf
libstdc++: use a link test to test for -Wl,-z,relro
Do a link test instead of just a grep. The linker can
support multiple targets, but not all targets can use it.
Signed-off-by: Jonathan Yong <10wa...@gmail.com>
---
diff --git a/libstdc++-v3/acinclude.m4 b/libstdc++-v3/acinclude.m4
index bc7d137dc74..209aa3a91f3 100644
--- a/libstdc++-v3/acinclude.m4
+++ b/libstdc++-v3/acinclude.m4
@@ -274,7 +274,16 @@ AC_DEFUN([GLIBCXX_CHECK_LINKER_FEATURES], [
ac_ld_relro=no
if test x"$with_gnu_ld" = x"yes"; then
AC_MSG_CHECKING([for ld that supports -Wl,-z,relro])
-cxx_z_relo=`$LD -v --help 2>/dev/null | grep "z relro"`
+ac_save_ldflags="$LDFLAGS"
+LDFLAGS="$LDFLAGS -Wl,-z,relro"
+AC_LINK_IFELSE([
+ AC_LANG_SOURCE(
+[[int main() { return 0; }]]
+ )],
+ [cxx_z_relo="1"],
+ [cxx_z_relo=""])
+ LDFLAGS="$ac_save_ldflags"
+
if test -n "$cxx_z_relo"; then
OPT_LDFLAGS="-Wl,-z,relro"
ac_ld_relro=yes
signature.asc
Description: OpenPGP digital signature
Re: [PATCH] Cygwin/MinGW: Do not version lto plugins
On 9/10/20 9:44 AM, Richard Biener wrote: >> >> I can confirm liblto is still loaded correctly from the logs, likewise >> renaming it away will cause an error. >> >> Seems to be fine on Linux. > > OK then. > > Thanks, > Richard. > Thanks for reviewing, pushed to master branch ae6cf62861b5e9acb518b016ddbe7f783206f65f. signature.asc Description: OpenPGP digital signature
Re: [PATCH] Cygwin/MinGW: Do not version lto plugins
On 9/9/20 7:32 AM, JonY wrote:
> On 9/9/20 7:21 AM, Richard Biener wrote:
>> On Wed, Sep 9, 2020 at 2:28 AM JonY via Gcc-patches
>> wrote:
>>>
>>> Hello,
>>>
>>> The lto plugis are tied to the built GCC anyway, so there isn't much
>>> point to versioning them.
>>
>> In fact the lto plugins are not tied to the built GCCs very much, instead
>> we try to ensure compatibility so that a single plugin can be used with
>> multiple GCC versions.
>>
>
> I see, I was not aware of this.
>
>>> * gcc/config.host: Remove version string
>>> * lto-plugin/Makefile.am: Use libtool -avoid-version
>>> * lto-plugin/Makefile.in: Regenerate
>>>
>>> This patch has been in use with Cygwin gcc for a long time and should be
>>> pushed upstream. Patch OK?
>>
>> The libtool docs are not very specific here but does this affect the
>> result for Linux ELF platforms at all?
>
> With current builds:
>
> /usr/libexec/gcc/x86_64-pc-linux-gnu/9.2.0/liblto_plugin.la
> /usr/libexec/gcc/x86_64-pc-linux-gnu/9.2.0/liblto_plugin.so
> /usr/libexec/gcc/x86_64-pc-linux-gnu/9.2.0/liblto_plugin.so.0
> /usr/libexec/gcc/x86_64-pc-linux-gnu/9.2.0/liblto_plugin.so.0.0.0
>
> With -avoid-version it will only generate liblto_plugin.so, from
> gcc/config.host, it is already what is loaded.
>
> I will do a native linux build to confirm this.
>
I did a bootstrap build of gcc on Linux and it produced the following
after installing:
libexec/gcc/x86_64-pc-linux-gnu/11.0.0/liblto_plugin.la
libexec/gcc/x86_64-pc-linux-gnu/11.0.0/liblto_plugin.so
I tested with the following command:
echo 'main(){}' | strace -f -o gcc.log -- ./inst/bin/gcc -xc - -v
-fuse-linker-plugin -o aa.out
I can confirm liblto is still loaded correctly from the logs, likewise
renaming it away will cause an error.
Seems to be fine on Linux.
signature.asc
Description: OpenPGP digital signature
Re: [PATCH] Cygwin/MinGW: Do not version lto plugins
On 9/9/20 7:21 AM, Richard Biener wrote: > On Wed, Sep 9, 2020 at 2:28 AM JonY via Gcc-patches > wrote: >> >> Hello, >> >> The lto plugis are tied to the built GCC anyway, so there isn't much >> point to versioning them. > > In fact the lto plugins are not tied to the built GCCs very much, instead > we try to ensure compatibility so that a single plugin can be used with > multiple GCC versions. > I see, I was not aware of this. >> * gcc/config.host: Remove version string >> * lto-plugin/Makefile.am: Use libtool -avoid-version >> * lto-plugin/Makefile.in: Regenerate >> >> This patch has been in use with Cygwin gcc for a long time and should be >> pushed upstream. Patch OK? > > The libtool docs are not very specific here but does this affect the > result for Linux ELF platforms at all? With current builds: /usr/libexec/gcc/x86_64-pc-linux-gnu/9.2.0/liblto_plugin.la /usr/libexec/gcc/x86_64-pc-linux-gnu/9.2.0/liblto_plugin.so /usr/libexec/gcc/x86_64-pc-linux-gnu/9.2.0/liblto_plugin.so.0 /usr/libexec/gcc/x86_64-pc-linux-gnu/9.2.0/liblto_plugin.so.0.0.0 With -avoid-version it will only generate liblto_plugin.so, from gcc/config.host, it is already what is loaded. I will do a native linux build to confirm this. signature.asc Description: OpenPGP digital signature
[PATCH] Cygwin/MinGW: Do not version lto plugins
Hello,
The lto plugis are tied to the built GCC anyway, so there isn't much
point to versioning them.
* gcc/config.host: Remove version string
* lto-plugin/Makefile.am: Use libtool -avoid-version
* lto-plugin/Makefile.in: Regenerate
This patch has been in use with Cygwin gcc for a long time and should be
pushed upstream. Patch OK?
From 6bf6b87887a8a5eb53ad409cd4aa32cb1ac50786 Mon Sep 17 00:00:00 2001
From: Jonathan Yong <10wa...@gmail.com>
Date: Sat, 28 Jun 2014 09:35:02 +0800
Subject: [PATCH 1/1] Cygwin/MinGW: Do not version lto plugins
---
gcc/config.host| 6 +++---
lto-plugin/Makefile.am | 2 +-
lto-plugin/Makefile.in | 2 +-
3 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/gcc/config.host b/gcc/config.host
index 84f0433e2ad..373d5efd8da 100644
--- a/gcc/config.host
+++ b/gcc/config.host
@@ -232,7 +232,7 @@ case ${host} in
out_host_hook_obj=host-cygwin.o
host_xmake_file="${host_xmake_file} i386/x-cygwin"
host_exeext=.exe
-host_lto_plugin_soname=cyglto_plugin-0.dll
+host_lto_plugin_soname=cyglto_plugin.dll
;;
i[34567]86-*-mingw32*)
host_xm_file=i386/xm-mingw32.h
@@ -240,7 +240,7 @@ case ${host} in
host_exeext=.exe
out_host_hook_obj=host-mingw32.o
host_extra_gcc_objs="${host_extra_gcc_objs} driver-mingw32.o"
-host_lto_plugin_soname=liblto_plugin-0.dll
+host_lto_plugin_soname=liblto_plugin.dll
;;
x86_64-*-mingw*)
use_long_long_for_widest_fast_int=yes
@@ -249,7 +249,7 @@ case ${host} in
host_exeext=.exe
out_host_hook_obj=host-mingw32.o
host_extra_gcc_objs="${host_extra_gcc_objs} driver-mingw32.o"
-host_lto_plugin_soname=liblto_plugin-0.dll
+host_lto_plugin_soname=liblto_plugin.dll
;;
i[34567]86-*-darwin* | x86_64-*-darwin*)
out_host_hook_obj="${out_host_hook_obj} host-i386-darwin.o"
diff --git a/lto-plugin/Makefile.am b/lto-plugin/Makefile.am
index ba5882df7a7..204b25f45ef 100644
--- a/lto-plugin/Makefile.am
+++ b/lto-plugin/Makefile.am
@@ -21,7 +21,7 @@ in_gcc_libs = $(foreach lib, $(libexecsub_LTLIBRARIES),
$(gcc_build_dir)/$(lib))
liblto_plugin_la_SOURCES = lto-plugin.c
# Note that we intentionally override the bindir supplied by ACX_LT_HOST_FLAGS.
liblto_plugin_la_LDFLAGS = $(AM_LDFLAGS) \
- $(lt_host_flags) -module -bindir $(libexecsubdir)
+ $(lt_host_flags) -module -avoid-version -bindir $(libexecsubdir)
# Can be simplified when libiberty becomes a normal convenience library.
libiberty = $(with_libiberty)/libiberty.a
libiberty_noasan = $(with_libiberty)/noasan/libiberty.a
diff --git a/lto-plugin/Makefile.in b/lto-plugin/Makefile.in
index 7da7cd26dbf..834699b439e 100644
--- a/lto-plugin/Makefile.in
+++ b/lto-plugin/Makefile.in
@@ -350,7 +350,7 @@ libexecsub_LTLIBRARIES = liblto_plugin.la
in_gcc_libs = $(foreach lib, $(libexecsub_LTLIBRARIES),
$(gcc_build_dir)/$(lib))
liblto_plugin_la_SOURCES = lto-plugin.c
# Note that we intentionally override the bindir supplied by ACX_LT_HOST_FLAGS.
-liblto_plugin_la_LDFLAGS = $(AM_LDFLAGS) $(lt_host_flags) -module \
+liblto_plugin_la_LDFLAGS = $(AM_LDFLAGS) $(lt_host_flags) -module
-avoid-version \
-bindir $(libexecsubdir) $(if $(wildcard \
$(libiberty_noasan)),, $(if $(wildcard \
$(libiberty_pic)),,-Wc,$(libiberty)))
--
2.11.4.GIT
signature.asc
Description: OpenPGP digital signature
Re: [PATCH] gcc: Make strchr return value pointers const
On 9/4/20 12:47 PM, Martin Storsjö wrote: > Hi, > > On Fri, 4 Sep 2020, Jakub Jelinek wrote: > >> On Tue, Sep 01, 2020 at 04:01:42PM +0300, Martin Storsjö wrote: >>> This fixes compilation of codepaths for dos-like filesystems >>> with Clang. When built with clang, it treats C input files as C++ >>> when the compiler driver is invoked in C++ mode, triggering errors >>> when the return value of strchr() on a pointer to const is assigned >>> to a pointer to non-const variable. >> >> Not really specific to clang, e.g. glibc does that in its headers too >> as the C++ standard mandates that (and I guess mingw should do that too). >> >>> This matches similar variables outside of the ifdefs for dos-like >>> path handling. >>> >>> 2020-09-01 Martin Storsjö >>> >>> gcc/Changelog: >>> * dwarf2out.c (file_name_acquire): Make a strchr return value >>> pointer to const. >>> >>> libcpp/Changelog: >>> * files.c (remap_filename): Make a strchr return value pointer >>> to const. >> >> LGTM. And it is short enough not to need copyright assignment, so ok for >> trunk. > > Thanks! Can someone commit this for me? > > // Martin Ping can anyone commit this? Are platform maintainers allowed to push general changes like these? If so I can push soon. signature.asc Description: OpenPGP digital signature
Re: [PATCH] gcc: Make strchr return value pointers const
On 9/1/20 1:01 PM, Martin Storsjö wrote: > This fixes compilation of codepaths for dos-like filesystems > with Clang. When built with clang, it treats C input files as C++ > when the compiler driver is invoked in C++ mode, triggering errors > when the return value of strchr() on a pointer to const is assigned > to a pointer to non-const variable. > Ping any reviewers? signature.asc Description: OpenPGP digital signature
Re: [PATCH] Port libgccjit to Windows.
On 6/12/20 12:19 AM, JonY wrote: > On 6/11/20 10:02 PM, Nicolas Bértolo wrote: >> Hi, >> >> On 6/7/20 11:12 PM, JonY wrote: >>> Ideally, libtool is used so we get libgccjit-0.dll, unfortunately it is >>> not. So the only way to ABI version the dll would be to use Unix style >>> soname to mark when an ABI has changed. >> >> I tried generating the library as libgccjit-0.dll and naming its import >> library >> libgccjit.dll.a. It worked. I understand you prefer the libgccjit-0.dll >> filename >> from this comment about libtool. A patch implementing this change is >> attached. >> >> Thanks for your feedback. >> >> Nicolas. >> > > Thanks for the patch, it looks good to me. I will push this soon if no > one else objects. > > Thanks, pushed to git master. signature.asc Description: OpenPGP digital signature
Re: [PATCH] Port libgccjit to Windows.
On 6/11/20 10:02 PM, Nicolas Bértolo wrote: > Hi, > > On 6/7/20 11:12 PM, JonY wrote: >> Ideally, libtool is used so we get libgccjit-0.dll, unfortunately it is >> not. So the only way to ABI version the dll would be to use Unix style >> soname to mark when an ABI has changed. > > I tried generating the library as libgccjit-0.dll and naming its import > library > libgccjit.dll.a. It worked. I understand you prefer the libgccjit-0.dll > filename > from this comment about libtool. A patch implementing this change is attached. > > Thanks for your feedback. > > Nicolas. > Thanks for the patch, it looks good to me. I will push this soon if no one else objects. signature.asc Description: OpenPGP digital signature
Re: [PATCH] Port libgccjit to Windows.
On 6/7/20 4:03 PM, Nicolas Bértolo wrote: > Hi, > > Sorry for the super late reply. > >> 1. Using .so on Windows for DLLs is fine. > > I know, but using the standard suffix for the platform seems better, IMHO. > It doesn't prevent applications from actually loading it. >> 2. The DLL name on Windows should use LIBGCCJIT_SONAME rather than >> LIBGCCJIT_LINKER_NAME, so applications would load libgccjit.so.0 instead >> of libgccjit.so directly. The linker command output needs to be >> LIBGCCJIT_SONAME. > > Do you think the library should be called libgccjit.so.0 instead of the more > Windows-like libgccjit.dll? That seems weird. Could you explain why? Ideally, libtool is used so we get libgccjit-0.dll, unfortunately it is not. So the only way to ABI version the dll would be to use Unix style soname to mark when an ABI has changed. Applications loading libgccjit.so.0 should be recompiled if a new incompatible ABI libgccjit.so.1 is introduced. If a recompile is not possible, the older library can still be installed side by side. Applications should still link against the file generated import library for transparency. signature.asc Description: OpenPGP digital signature
Re: [PATCH] Port libgccjit to Windows.
On 5/28/20 8:46 PM, David Malcolm via Gcc-patches wrote: > On Thu, 2020-05-28 at 16:51 -0300, Nicolas Bértolo wrote: >>> I'm going to have to trust your Windows expertise here; the tempdir >>> code looks convoluted to me, but perhaps that's the only way to do >> it. >>> (Microsoft's docs for "SECURITY_ATTRIBUTES" suggest to me that if >>> lpSecurityDescriptor is NULL, then the directory gets a default >>> security descriptor, and that this may mean it's only readable by >> the >>> user represented by the access token of the process [1], which >> might >>> suggest a simplification - but I'm very hazy on how the security >> model >>> in Windows works) >> >> I tested this and it gives write access to the "Authenticated Users" >> group. > > Aha - sounds like that would be a problem. Thanks for clarifying. > >> The >> way I did it gives access only to the user that owns the libgccjit >> process. I >> have to admit that it is a lot of code and it is hard to understand >> unless you >> know the security model of Windows well. I don't know it well, I >> wrote this >> keeping the documentation close and experimenting. > > Thanks. > >>> I was able to successfully bootstrap and regression test with your >>> patch on x86_64-pc-linux-gnu. I also verified that the result of >> "make >>> install" was not affected for my configuration. >> >> Great. >> >>> I've pushed your patch to master as >>> c83027f32d9cca84959c7d6a1e519a0129731501. >>> >>> Thanks again for the patch >>> Dave >> >> Thanks to you for all the good feedback. >> >> Nico. > Hello, A bit of a late review, some minor points: 1. Using .so on Windows for DLLs is fine. 2. The DLL name on Windows should use LIBGCCJIT_SONAME rather than LIBGCCJIT_LINKER_NAME, so applications would load libgccjit.so.0 instead of libgccjit.so directly. The linker command output needs to be LIBGCCJIT_SONAME. 3. Ideally I would prefer to .cc too, though I see other C++ files also written as .c. Resend in case reply to list did not work, signature.asc Description: OpenPGP digital signature
Re: [PATCH] Ensure `-lmsvcrt` precede `-lkernel32`
On 5/29/20 2:04 PM, Liu Hao via Gcc-patches wrote:
> 在 2020/5/29 22:01, Liu Hao 写道:
>> This is necessary as libmsvcrt.a is not a pure import library, but
>> also contains some functions that invoke others in KERNEL32.DLL.
>>
>> * config/i386/mingw32.h: Insert -lkernel32 after -lmsvcrt
>> ---
>> gcc/config/i386/mingw32.h | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/gcc/config/i386/mingw32.h b/gcc/config/i386/mingw32.h
>> index 1bbabfe8bed..321c30e41cc 100644
>> --- a/gcc/config/i386/mingw32.h
>> +++ b/gcc/config/i386/mingw32.h
>> @@ -165,7 +165,7 @@ along with GCC; see the file COPYING3. If not see
>> #define REAL_LIBGCC_SPEC \
>>"%{mthreads:-lmingwthrd} -lmingw32 \
>> " SHARED_LIBGCC_SPEC " \
>> - -lmoldname -lmingwex -lmsvcrt"
>> + -lmoldname -lmingwex -lmsvcrt -lkernel32"
>> #undef STARTFILE_SPEC
>> #define STARTFILE_SPEC "%{shared|mdll:dllcrt2%O%s} \
>>
>
> This patch originates from this discussion on #mingw-w64 on OFTC:
>
> ```
> [20:09:50] there is suddenly an unexpected call to
> `IsDBCSLeadByteEx()` in winpthreads. Not sure why it gets involved.
> [20:13:12] * tchan (~tc...@c-98-220-238-152.hsd1.il.comcast.net) has joined
> [20:22:28] diff'ing the import tables the previous working
> binary and now broken binary reveals that the old symbol to `printf` is
> gone. seems the mingw-w64 ones is called, which references
> `IsDBCSLeadByteEx()` and `WideCharToMultiByte()`.
> [20:27:19] both of those should be provided by -lkernel32 right?
> [20:27:36] * Dejan has quit (Quit: Leaving)
> [20:34:09] probably, but I doubt whether it should behave
> this way. when perform cross-compilation the CRT is not available when
> building winpthreads.
> [20:34:37] presumably it should always call the MS one.
> [20:34:45] I'm pretty sure you'd first build the crt, then
> libraries like winpthreads - the other way around doesn't work
> [20:35:16] :| let me make a test program.
> [20:38:38] can't reproduce it myself.
> [20:41:06] there may be something wrong with the OP'
> [20:41:18] 's configuration. Normally kernel32 is a default lib.
> [20:42:39] I still think winpthreads should be built with
> `CPPFLAGS='-D__USE_MINGW_ANSI_STDIO=0'`. I built a local package and
> there is no reference to DBCS or wide char functions.
> [20:49:21] reproduced now:
> https://paste.ubuntu.com/p/HwNk8WqgkD/
> [20:49:23] Title: Ubuntu Pastebin (at paste.ubuntu.com)
> [20:52:45] strange: -lmingw32 -lgcc -lgcc_eh -lmoldname
> -lmingwex -lmsvcrt -lpthread -lmcfgthread -ladvapi32 -lshell32 -luser32
> -lkernel32 -lmingw32 -lgcc -lgcc_eh -lmoldname -lmingwex -lmsvcrt
> [20:53:10] oh.
> [20:53:22] the mingw-w64 `printf` is defined in mingwex I guess?
> [20:53:22] pthread pulls in objects from msvcrt, which then needs
> things from kernel32, but there's no more kernel32 after msvcrt
> [20:54:04] in 211af1e7d4d188dbefacea7af8b83d32b3edb48c I moved
> mbrtowc and wcrtomb from mingwex to msvcrt
> [20:54:37] (but that wouldn't make a difference wrt this, as
> there's no kernel32 after the first mingwex after -lpthread either)
> [20:55:10] I think it would be good with yet another -lkernel32
> after -lmsvcrt
> [20:55:27] after all, that's the way they are layered anyway - the
> crt runs on top of kernel32
> [20:56:32] and we want to have the freedom to have object file
> implementations in libmsvcrt.a
> [20:58:21] some of these -l things are hard-coded in GCC
> default specs.
> [20:58:48] I only found `-ladvapi32 -lshell32 -luser32
> -lkernel32`. The list ends there.
> [20:59:11] not sure how those additional libraries were added.
> [21:00:04] lld is nice in this aspect, that it doesn't need static
> libraries ordered like this; for each undefined, it searches the list of
> static libraries from the start
> [21:01:07] LD is dumb. :(
> [21:02:53] I thought MSVCRT was only an import library. It
> seems more complicated.
> [21:04:18] it has (almost) always been more than that - there's
> been some stub functions that call GetProcAddress() and try to
> conditionally load functions if available
> [21:04:53] and especially with ucrt, we want to move quite a bit
> of things from libmingwex.a to libmsvcrt-os.a, for things where we can
> and should use the ucrt equivalent instead of statically linking in our own
> [21:05:32] GetProcAdress() requires a successive -lkernel32 too.
> [21:05:45] indeed
> [21:06:56] so this suddenly becomes a GCC issue in its
> default specs: `-lkernel32` is required after `-lmsvcrt`.
> [21:07:33] yes, pretty much. clang has got the same structure as well
> [21:07:44] (which matters for cases when using clang on top of ld.bfd)
> [21:08:48] looks like it's REAL_LIBGCC_SPEC in
> gcc/config/i386/mingw32.h that needs to be updated
> ```
>
>
>
Thanks pushed to master.
signature.asc
Description: OpenPGP digital signature
Re: [PATCH] Port libgccjit to Windows.
On 5/28/20 8:46 PM, David Malcolm via Gcc-patches wrote: >>> I was able to successfully bootstrap and regression test with >>> your patch on x86_64-pc-linux-gnu. I also verified that the >>> result of >> "make >>> install" was not affected for my configuration. >> >> Great. >> >>> I've pushed your patch to master as >>> c83027f32d9cca84959c7d6a1e519a0129731501. >>> >>> Thanks again for the patch Dave >> >> Thanks to you for all the good feedback. >> >> Nico. > Hello, A bit of a late review, some minor points: 1. Using .so on Windows for DLLs is fine. 2. The DLL name on Windows should use LIBGCCJIT_SONAME rather than LIBGCCJIT_LINKER_NAME, so applications would load libgccjit.so.0 instead of libgccjit.so directly. The linker command output needs to be LIBGCCJIT_SONAME. 3. Ideally I would prefer to .cc too, though I see other C++ files also written as .c. signature.asc Description: OpenPGP digital signature
