Dear Keith, I really appreciate your answer. Here are some notes: - I will try to raise the issue with my team leader - the web site www.mingw.org nor the installation process does not mention trademark as far as I can see. - the link to http://www.mingw.org/wiki/MinGW_licensing listed in http://www.mingw.org/wiki/FAQ#toc11 should be probably changed to http://www.mingw.org/license - can GCC compiler provided by MinGW generate 64-bit binaries? A brief test tells me: C:\temp>gcc --version g++ (MinGW.org GCC-8.2.0-3) 8.2.0 ... C:\temp>g++ -m64 -c -o foo.o foo.c cc1plus.exe: sorry, unimplemented: 64-bit mode not compiled in This may be the reason why I got my hands on mingw-w64. -- bye rastos On 27/05/2019 17.04, Keith Marshall wrote: > On 27/05/19 09:05, Rastislav Stanik wrote: >> I've hit a problem when compiling my project with >> gcc --version >> gcc (x86_64-win32-sjlj-rev0, Built by MinGW-W64 project) 8.1.0 > > First, let's make it completely clear: this compiler originates from a > third party project which illegally uses our registered trademark, > without our authorization; it is NOT a MinGW product, and is not > supported here. > >> I'm trying to build a 32-bit (using -m32) shared library that uses >> PCRE (Perl Compatible Regular Expressions library) compiled by myself >> using the same compiler. At linking stage I get a report about >> missing symbol __chkstk_ms: >> >> {MinGW-root}/bin/../lib/gcc/x86_64-w64-mingw32/8.1.0/../../../../x86_64-w64-mingw32/lib/../lib32/libmingw32.a(lib32_libmingw32_a-pseudo-reloc.o):pseudo-reloc.c:(.text+0x18d): >> undefined reference to `__chkstk_ms' >> >> Reference to __chkstk_ms() is added by compiler when some function >> declares local variables exceeding page size (~4k). > > Amongst other reasons. > >> In my case the function that exceeds the limit is in PRCE, so I >> cannot simply work around it in my code. The function __chkstk_ms() >> is provided by libgcc.a located in directory >> >> {MinGW-root}/lib/gcc/x86_64-w64-mingw32/8.1.0/32/ >> >> So if I add linking of that libgcc.a then the linking stage succeeds. >> But I also have to ensure that libgcc.a is in link search path. >> >> Questions: >> - why the compiler does not add libgcc.a by itself when it added >> __chkstk_ms() by itself? > > Our distribution does exactly that; irrespective of whether or not > __chkstk_ms() is referenced, -lgcc is specified by default, and the > appropriate path is also specified. > >> - if I add -lgcc, why do I also have to add path with -L? Shouldn't >> the directory be in the default linker search path? - is there a >> solution that will keep working after next release of MinGW/GCC when >> the path to libgcc changes? > > You aren't using a genuine MinGW product, so who knows? A possible > explanation could be that your build system is trying to invoke ld > directly, rather than letting gcc do the linking ... you don't show the > actual link command. If you don't indulge in that misguided shortcut, > then this problem should not arise, with our GCC-8.2.0 > > > _______________________________________________ > MinGW-Users mailing list > MinGW****@lists***** > > This list observes the Etiquette found at > http://www.mingw.org/Mailing_Lists. > We ask that you be polite and do the same. Disregard for the list etiquette may cause your account to be moderated. > > _______________________________________________ > You may change your MinGW Account Options or unsubscribe at: > https://lists.osdn.me/mailman/listinfo/mingw-users > Also: mailto:mingw****@lists*****?subject=unsubscribe >
Fork