Activity for Brecht Sanders
-
Brecht Sanders posted a comment on ticket #3
No installation is necessary. The unzipped archive provides the command line tools ready to use. I strongly advise against making system-wide changes to the PATH environment variable. Instead point your IDE to the full paths of the tools you want to use. An example on how to do this for Code::Blocks is explained here: https://winlibs.com/#usage-codeblocks For Visual Studio Code it should be pretty much the same. I do you hope you mean Visual Studio Code (the IDE) and not the full Visual Studio programming...
-
Thanks. Do you normally consider master to be stable enough for production?
-
Release version / release schedule
-
undefined reference to `xb::operator<<(std::ostream&, xb::xbString const&)
-
Use -static-libstdc++ / -static-libstdc++ in combination with -static so not only standard libraries are statically linked, but also any others (like -lwinpthread).
-
Sure, my build script is published here: https://github.com/brechtsanders/winlibs_recipes/blob/main/recipes/xbase64.winlib
-
I figured out how to build 4.1.0 with MinGW-w64. I just used the build/debian/CMakeLists.txt after applying the following changes: patch -ulbf build/debian/CMakeLists.txt << EOF @@ -370,6 +370,6 @@ # Microsoft Windows settings -IF( WIN32 ) +IF( MSVC ) # add_definitions( /D_CRT_SECURE_NO_WARNINGS) add_definitions( /EHsc ) -ENDIF( WIN32 ) +ENDIF( MSVC ) @@ -707,3 +707,3 @@ -install (FILES include/xbconfig.h +install (FILES \${PROJECT_BINARY_DIR}/include/xbconfig.h \${PROJECT_SOURCE_DIR}/include/xbase.h...
-
Correction, I see some CMakeLists.txt files under build/* but which one is for MinGW-w64?
-
Missing CMake build files in release 4.1.0
-
Typo in gdiplusbrush.h: RotateTranform
-
-
Bug reported here: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=53479
-
A similar match with cl* happens in mingw-w64-libraries/winpthreads/m4/libtool.m4
-
clang identified as MSVC because of cl* match in mingw-w64-libraries/winpthreads/configure
-
Note that I'm still having issues, even with latest GCC releases with regards to stack protector dependancies and MinGW-w64. Are there any tips on how to build GCC to avoid stack protector issues?
-
Unable to build mingw-w64-libraries/winstorecompat in version 9.0.0
-
-
-
Yes, WSAStartup() must be called manually at the beginning of each program when using winsock in MinGW. Looking forward to your next release :-)
-
Great work. Just a tip but getaddrinfo sometimes requires this to work properly: #define _WIN32_WINNT 0x0501 #include <ws2tcpip.h> Were there any build warnings?
-
I use the latest build from http://winlibs.com/ http://winlibs.com/ There is also a MinGW-w64 that you can install via the package manager of MSYS2 from https://sourceforge.net/projects/msys2/files/Base/ https://sourceforge.net/projects/msys2/files/Base/ I will try to fork again to see if it's okay then. On 13/12/2020 21:09, Corey Minyard wrote: On Sun, Dec 13, 2020 at 04:50:30PM -0000, Brecht Sanders wrote: I looked and for example lib/domain.c didn't have my changes. Maybe I was looking in the...
-
I looked and for example lib/domain.c didn't have my changes. Maybe I was looking in the wrong place? Should I fork it again to be sure? I'm using the latest MinGW-w64. If you're using the old MinGW it's possible that inet_ntop/inet_pton is not there. Brecht Sanders Edustria | MailTester.com | WinLibs.com E-mail: brecht@sanders.org brecht@sanders.org On 13/12/2020 17:12, Corey Minyard wrote: On Sun, Dec 13, 2020 at 02:21:23PM -0000, Brecht Sanders wrote: I see a lot of the stuff from my pull request...
-
I see a lot of the stuff from my pull request is still missing when I make a new fork of the github repository. Is it possible not everything got merged? On 12/12/2020 21:28, Corey Minyard wrote: On Sat, Dec 12, 2020 at 05:23:55PM -0000, Brecht Sanders wrote: That fix didn't do the trick. I still get: |`` d:/prog/winlibs64-10.2.0-8.0.0/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: .libs/ipmi.o: in function|ipmi_shutdown': \SERVER\users\brecht\sources\CPP_forks_\OpenIPMI\lib/ipmi.c:612:...
-
Also, to build make -Cglib some missing exports need to be fixed: patch -ulbf glib/glib_os_hnd.c << EOF @@ -858,3 +858,3 @@ -os_handler_t * +IPMI_DLL_PUBLIC os_handler_t * ipmi_glib_get_os_handler(int priority) @@ -923,3 +923,3 @@ -void +IPMI_DLL_PUBLIC void ipmi_glib_set_log_handler(void (*hndlr)(const char *domain, EOF
-
That fix didn't do the trick. I still get: d:/prog/winlibs64-10.2.0-8.0.0/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: .libs/ipmi.o: in function `ipmi_shutdown': \\SERVER\users\brecht\sources\CPP\_forks_\OpenIPMI\lib/ipmi.c:612: undefined reference to `ipmi_malloc_shutdown' d:/prog/winlibs64-10.2.0-8.0.0/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: .libs/ipmi.o: in function `ipmi_init': \\SERVER\users\brecht\sources\CPP\_forks_\OpenIPMI\lib/ipmi.c:474:...
-
Just created pull request https://github.com/cminyard/openipmi/pull/3 with what I believe needs to be fixed. Well almost. Still 3 undefined references: ipmi_malloc_shutdown/ipmi_malloc_init/ipmi_malloc_log
-
Forgot to mention: declspec(dllexport) and declspec(dllimport) work fine on Cygwin too.
-
It did require some tweaking from my part to get it to build on native Windows with MinGW-w64. Here are some of those tricks I used: # create dummy syslog.h cat > syslog.h << EOF #define LOG_ERR 3 static void syslog (int priority, const char *format, ...) {} EOF # fix missing includes mkdir netinet sys arpa echo "#include <winsock2.h>" > netinet/in.h touch netdb.h touch sys/socket.h touch arpa/inet.h touch sys/poll.h echo "#include <malloc.h>" > alloca.h ./configure --with-openssl --with-ucdsnmp...
-
Not quite there yet... Now you gave cases where either IPMI_UTILS_DLL_PUBLIC or IPMI_UTILS_DLL_PUBLIC are not defined, leading to compilation errors. Also, you seem to make a distinction based on __GNUC__ which I don't think is needed as both MinGW-GCC and MSVC understand __declspec(dllexport)/__declspec(dllimport). See here for a clean example on how I usually do this: https://github.com/brechtsanders/ci-test/blob/master/include/mylibrary.h
-
This doesn't fix it: patch -ulbf include/OpenIPMI/internal/ilist.h << EOF @@ -224,5 +224,3 @@ /* You must define these. */ -IPMI_DLL_PUBLIC void *ilist_mem_alloc(size_t size); -IPMI_DLL_PUBLIC void ilist_mem_free(void *data); EOF Note that make -Cutils works fine. The errors start when running make -Clib and there's a lot of them (see attachment). When a project generates multiple DLLs you should separate defines per library for the dllexport/dllimport stuff, as it is possible some functions are...
-
OpenIPMI 2.0.30 no longer builds with MSYS/MinGW
-
Building with MSYS2/MinGW-w64
-
-
Is there any progress on this issue?
-
@ktietz70 I'm sorry, but I'm not following where you think this wrong assumtion was made. Is this in both gcc and pkg-config source code? Or are you referring to some other code?
-
Similar issues building win64 build of pkg-config. There I got it to build by adding #define __USE_MINGW_ANSI_STDIO 0 at the top of glib/glib/gslice.c. Did something change to the definition of __USE_MINGW_ANSI_STDIO in MinGW-w64 v8.0.0?
-
MinGW-w64 8.0.0 fails with printf format errors in libgomp/target.c and libgomp/oacc-parallel.c
-
xpm data corrupt in src/icons.h
-
Hi, I just had a look at BlitzMax and it seems to be targeted at MinGW-w64 with GCC 8.1.0. Looking at https://github.com/blitz-research/blitzplus I couldn't really find its proper C/C++ source to build it from scratch. I believe it's a bad idea to mix compilers within a project. Especially if different standard libraries come into play and when C++ exception handling is used. As your application http://pocketradio.awardspace.info/ isn't a game these days it would make more sense to use wxWidgets...
-
Hi Stefan, Is the work you're trying to build open source? If so, I don't mind trying to build it in my environment where I have built every dependancy from scratch using the same compiler. Brecht On 01/05/2020 10:41, Stefan Sarbok wrote: I have tested the 7.5 build and so far it works as expected. Thanks a lot for your help. Btw, do you have a paypal account. I would like to make a small donation for the work you had. P.S.: I can't figure out why newer versions don't work anymore. When my code is...
-
As E.Naumovich mentioned I was able to make my personal build with GCC 7.5 which I published on: http://winlibs.com/ Or you can download it directly from: https://github.com/brechtsanders/winlibs_mingw/releases/tag/7.5.0-7.0.0-r1
-
-
-
I chose to avoid SEH on the basis that it imposes a larger performance overhead. The POSIX threading was chosen over WIN32 because the C++ thread implementation is less compatible with and causes certain packages not to build properly. My goal was to have te most optimal and portable solution, so I didn't built the alternatives. About your basic_stringstream errors: note that the ABI changed, so linking stuff compiled with different GCC versions is likely to cause such problems. Personally I rebuild...
-
No, some projects were not using autoconf/libtool. That is why I was using libscrypt as an interesting case to reproduce ths problem. The steps to reproduce are: wget -c https://github.com/technion/libscrypt/archive/v1.21.tar.gz tar xfz v1.21.tar.gz cd libscrypt-1.21 sed -e "s/-Wl,-z,now\|-Wl,-z,relro\|-lc//g; s/-Wl,-soname,\([a-z]*\)\.so\.[0-9]*/-s -Wl,--out-implib,\1.dll.a/; s/\.so\.[0-9]*/.dll/g; s/ln -s/echo SKIPPING &/g" Makefile > Makefile.mingw make -f Makefile.mingw CC=gcc When using gcc...
-
I just wanted to let you know that I have built GCC 9.2.0 with --enable-default-ssp and used that to build a number of libraries. It appears however this does not resolve the problem, i.e. linking still requires -fstack-protector or -lssp to resolve the undefined references.
-
That's great news. I use it myself in Code::Blocks on Windows. GCC development on version 10 is in progress, and I'm constantly keeping an eye out for new releases.
-
I just found out GCC can be built with an option --enable-default-ssp. I will try that and see if my entire package collection builds fine with a GCC built like that.
-
Okay. I will change my building recipes to work around the problem by linking with -lssp whenever needed. In many cases adding this after the ./configure line works: LIBS="-Wl,--as-needed -lssp" For example mono builds fine now after only adding this. On the other had gdb needed a lot more tweaking, but I got it to build in the end. I have added this solution to the web page of my personal standalone build at: http://winlibs.com/. You can go ahead and close this ticket.
-
I get that, but I'm still confused. If I used the same GCC version with MinGW-w64 6.0.0 it worked, but with MinGW-w64 7.0.0 it's broken. If this new version broke it, why can't it be fixed there? Isn't it a goal of MinGW-w64 to be able to compile sources for Windows with as little changes as possible to the source packages?
-
Could it be an option to always export the __*_chk functions so these link errors can be avoided if any component in the link process needs them?
-
What will be done to solve this issue? In the meantime I also noticed the following packages also won't build with MinGW-w64 7.0.0: - acpica - gdb - hashdeep - htmldoc - libopus - libressl - libsndfile - libsodium - openttd - ruby - stunnel - xapian Some of these were mentioned in #5803. So it' clearly breaking multiple builds that were working before (with MinGW-w64 6.0.0).
-
What will be done to solve this issue? In the meantime I also noticed the following packages also won't build with MinGW-w64 7.0.0: acpica gdb hashdeep htmldoc libopus libressl libsndfile libsodium openttd ruby stunnel xapian Some of these were mentioned in #5803. So it' clearly breaking multiple builds that were working before (with MinGW-w64 6.0.0).
-
What will be done to solve this issue? In the meantime I also noticed the following packages also won't build with MinGW-w64 7.0.0: acpica gdb hashdeep htmldoc libopus libressl libsndfile libsodium openttd ruby stunnel xapian Some of these were mentioned in #5803. So it' clearly breaking multiple builds that were working before (with MinGW-w64 6.0.0).
-
I did some more tests and figured out -fstack-protector is also needed when linking, not just when compiling. Several projects don't seem to configure their build systems like this (so for I found this to be true for libscrypt and cairo). These libraries did build against MinGW-w64 6.0.0 with the same compiler (GCC 9.2). What exactly changed?
-
I did some more tests and figured out -fstack-protector is also needed when linking, not just when compiling. Several projects don't seem to configure their build systems like this (so for I found this to be true for libscrypt and cairo. These libraries did build against MinGW-w64 6.0.0 with the same compiler (GCC 9.2). What exactly changed?
-
Just noticed building cairo (v1.16.0) with MinGW-w64 7.0.0 also fails with undefined reference to '__strncat_chk'
-
When I add this to Makefile.mingw to make sure the compiler options is specified after the .o files: %.o: %.c $(CC) -c -o $@ $< $(CFLAGS) this is the output: $ make -f Makefile.mingw CC=gcc V=1 && echo OK gcc -c -o crypto_scrypt-nosse.o crypto_scrypt-nosse.c -O2 -Wall -g -D_FORTIFY_SOURCE=2 -fstack-protector -lssp gcc -c -o sha256.o sha256.c -O2 -Wall -g -D_FORTIFY_SOURCE=2 -fstack-protector -lssp gcc -c -o crypto-mcf.o crypto-mcf.c -O2 -Wall -g -D_FORTIFY_SOURCE=2 -fstack-protector -lssp gcc -c...
-
With -lssp I still get undefined reference to '__strcpy_chk' When using -fstack-protector -lssp I get:d:/prog/winlibs64-9.2.0-7.0.0/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/9.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: sha256.o: in function 'libscrypt_SHA256_Final': R:\winlibs64-9.2.0-7.0.0\libscrypt-1.21/sha256.c:290: undefined reference to '__stack_chk_fail' d:/prog/winlibs64-9.2.0-7.0.0/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/9.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: sha256.o: in...
-
Problem seems to be solved in the meantime.
-
Because then I had other issues. If I leave it in I get: R:\winlibs32-9.2.0-7.0.0\libscrypt-1.21/crypto_scrypt-check.c:17: undefined reference to `__stack_chk_guard' d:/prog/winlibs32-9.2.0-7.0.0/mingw32/bin/../lib/gcc/i686-w64-mingw32/9.2.0/../../../../i686-w64-mingw32/bin/ld.exe: R:\winlibs32-9.2.0-7.0.0\libscrypt-1.21/crypto_scrypt-check.c:104: undefined reference to `__stack_chk_guard' d:/prog/winlibs32-9.2.0-7.0.0/mingw32/bin/../lib/gcc/i686-w64-mingw32/9.2.0/../../../../i686-w64-mingw32/bin/ld.exe:...
-
Seems similar to this post in the mailing list: https://sourceforge.net/p/mingw-w64/mailman/message/36764708/ At the end of the thread there was a mention of a patch being pushed. Was this not included in release 7.0.0 released at the following link? http://sourceforge.net/projects/mingw-w64/files/mingw-w64/mingw-w64-release/
-
undefined reference to `__strcpy_chk' with -D_FORTIFY_SOURCE=2 or -D_FORTIFY_SOURCE=1
-
I just released my personal build of MinGW-w64 7.0.0 with GCC 9.2 here: http://winlibs.com/
-
Basically the -static linker flag is what you need. Use the additional -static-libgcc and -static-libstdc++ flags to use also the static standard library. For example example, if you have these files in your library path (e.g. via -L linker flag): libz.a libz.dll.a the following command will build use the static library (libz.a): gcc -static -o test.exe test.c -static-libgcc -lz and this will use the shared library (libz.dll.a): gcc -shared -o test.exe test.c -static-libgcc -lz It's important to...
-
v7.0.0 downloads contain folder mingw-w64-v6.0.0
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
Looks better now, except for this error: Cannot export lame_init_old: symbol not defined But I was able to build both static and shared libraries for Windows after removing lame_init_old from include/libmp3lame.sym.
-
v3.100 breaks Windows compatibility
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
1 >
