This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [patch i386]: PR/39356 name collision of __chkstk
> no there is no ___chkstk symbol in libgcc_s (even for 64-bit). The
> issue seems to more related to link order itself. For some reason, the
> link library libkernel32.a (which exports just for 64-bit ___chkstk,
> too) gets used to resolve the symbol, before the libgcc.a is linked.
>
Finally, I think I may see the problem.
Look at SHLIB_LINK in t-cygming:
SHLIB_LINK = $(LN_S) -f $(SHLIB_MAP) $(SHLIB_MAP).def && \
if [ ! -d $(SHLIB_DIR) ]; then \
mkdir $(SHLIB_DIR); \
else true; fi && \
$(GCC_FOR_TARGET) $(LIBGCC2_CFLAGS) -shared -nodefaultlibs \
$(SHLIB_MAP).def \
-Wl,--out-implib,$(SHLIB_DIR)/$(SHLIB_IMPLIB).tmp \
-o $(SHLIB_DIR)/$(SHLIB_SONAME).tmp @multilib_flags@ \
$(SHLIB_OBJS) $(SHLIB_LC) ...
SHLIB_LC includes -lkernel32. The -nodefaultlibs excludes libgcc, so
kernel32 __chkstk gets linked in.
Just to test my speculation, could you see if
Index: t-cygming
===================================================================
--- t-cygming (revision 144975)
+++ t-cygming (working copy)
@@ -51,7 +51,7 @@
SHLIB_SOVERSION = 1
SHLIB_SONAME = @shlib_base_name@_$(EH_MODEL)-$(SHLIB_SOVERSION)$(SHLIB_EXT)
SHLIB_MAP = @shlib_map_file@
-SHLIB_OBJS = @shlib_objs@
+SHLIB_OBJS = @shlib_objs@ _chkstk.o
SHLIB_DIR = @multilib_dir@/shlib
SHLIB_SLIBDIR_QUAL = @shlib_slibdir_qual@
also fixes the bug.