Re: [Mingw-w64-public] cannot execute ./configure
The MinGW-w64 project only provides the software needed to make a GCC toolchain on Windows. Since you are trying to execute "configure", which is a shell script, you need to get a shell like Bash running on your computer, and that is outside of the scope of the MinGW project. I recommend ignoring whatever you downloaded earlier and installing MSYS2, which comes with Bash and a package manager you can use to install MinGW toolchains: https://www.msys2.org/ If you ask a question on StackOverflow.com and tag it with "msys2", I will see it. Be sure to provide all the specific details about what you are trying to compile, what MSYS2 environment you are using, what MSYS2 packages you installed, what you tried, and the full error messages you got. --David Grayson On Thu, Nov 30, 2023 at 9:09 AM Frère Justin - Jérusalem < frere.jus...@fraternites-jerusalem.org> wrote: > Hi there... I installed mingw64 for windows a year ago or so. I'm trying to > install a library for unix. I have downloaded the source file and > uncompressed it; in order to finalize the installation, I mut run > ./configure (I guess from the mingw64 directory) but then I get the > following error message (I translate from italian): "." is not recognized > as an internal or external command, an executable file or a batch file > Do you figure out what I'm missing ? Thx ! > > Justin > > ___ > Mingw-w64-public mailing list > Mingw-w64-public@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/mingw-w64-public > ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Is wmain supported?
I tested it just now and it appears to be supported. Pass the -municode option to GCC. --David On Tue, Jan 3, 2023 at 11:23 AM Luca Bacci wrote: > Hi, > > Is wmain supported by mingw GCC or CLang? > https://learn.microsoft.com/en-us/cpp/c-language/using-wmain > > Otherwise where is the crt source code that creates the argv vector from > the command line? > > Thank you very much! > Luca > > ___ > Mingw-w64-public mailing list > Mingw-w64-public@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/mingw-w64-public > ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Patches for GCC
I'm not too excited about it. The patches apply to GCC 8, so they're a bit too stale to submit. Two of the patches came from gcc.gnu.org so I think they were already submitted. The rest of the patches are more like opinions or configuration desires, so they might trigger debates and cause problems for users with different opinions. --David Grayson On Sat, Dec 4, 2021 at 1:35 PM NightStrike wrote: > On Thu, Nov 11, 2021 at 2:43 PM David Grayson > wrote: > > > > Here is my recipe for building a GCC 8.2.0 cross-compiler targeting > > mingw-w64. It includes 6 patches, and comments about why they were > > needed. It looks like one of those patches did fix an internal compiler > > error that happened when compiling Qt. > > > > > https://github.com/DavidEGrayson/nixcrpkgs/blob/master/mingw-w64/gcc/default.nix > > Can you submit these to GCC so that local patches aren't needed? > > > ___ > Mingw-w64-public mailing list > Mingw-w64-public@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/mingw-w64-public > ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Patches for GCC
Here is my recipe for building a GCC 8.2.0 cross-compiler targeting mingw-w64. It includes 6 patches, and comments about why they were needed. It looks like one of those patches did fix an internal compiler error that happened when compiling Qt. https://github.com/DavidEGrayson/nixcrpkgs/blob/master/mingw-w64/gcc/default.nix I haven't compiled as many packages as the MSYS2 developers, so that's probably why I didn't need so many patches. --David Grayson On Thu, Nov 11, 2021 at 11:37 AM Kacvinsky, Tom wrote: > Are these the patches necessary for building GCC for MSYS2/MinGW-w64? > > https://github.com/msys2/MINGW-packages/blob/master/mingw-w64-gcc/PKGBUILD > > I ask because I keep getting internal compiler errors, and I think one or > more of these > patches would help. I think I might need to apply patches for binutils, > as well. > > What I am doing is using the UCRT64 tool chain to bootstrap another UCRT64 > tool chain > (for starters) _and_ test it with the GCC test suite. Once I am satisfied > with that, I will > then proceed to making my patches for what I hope to be a fix for MSVC <-> > GCC SEH > exception handling. > > Thanks, > > TOm > > From: Kacvinsky, Tom > Sent: Thursday, November 4, 2021 10:46 PM > To: 'mingw-w64-public@lists.sourceforge.net' < > mingw-w64-public@lists.sourceforge.net> > Subject: RE: Patches for GCC > > I think this is it > > https://github.com/msys2/MINGW-packages > > Tom > > P.S. - I would bottom post but Outlook is being a pain with > quoting emails. > > From: Kacvinsky, Tom > Sent: Thursday, November 4, 2021 9:12 PM > To: 'mingw-w64-public@lists.sourceforge.net' < > mingw-w64-public@lists.sourceforge.net mingw-w64-public@lists.sourceforge.net>> > Subject: Patches for GCC > > Hi all, > > I am back to futzing around with building GCC with UCRT support. > I have run into several weird issues that I think might be fixed in > patches made by the MinGW-w64 team. I know I've been able to > find those patches in the past, but my Google-fu is weak and I do > not see them anywhere. > > > > ___ > Mingw-w64-public mailing list > Mingw-w64-public@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/mingw-w64-public > ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] "pacman -S mingw-w64-ucrt-x86_64-toolchain" not working
The command "pacman -S mingw-w64-ucrt-x86_64-toolchain" works for me (at least as far as finding the names of the packages to install). Does your system have /etc/pacman.d/mirrorlist.ucrt64 ? Maybe you need to run "pacman -Syuu" a few times to get that file and update everything. --David Grayson On Tue, Nov 9, 2021 at 11:34 AM Kacvinsky, Tom wrote: > I ran the command in the subject line, but got this: > > $ pacman -S mingw-w64-ucrt-x86_64-toolchain > error: target not found: mingw-w64-ucrt-x86_64-toolchain > > Is there some repo I need to add? It's not clear from this page > > https://packages.msys2.org/group/mingw-w64-ucrt-x86_64-toolchain > > Thanks, > > Tom > > ___ > Mingw-w64-public mailing list > Mingw-w64-public@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/mingw-w64-public > ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Pathing issue
What type of make.exe are you running? MSYS2 or MinGW? (Hint: type `which make` in Bash.) How exactly are you running it? From a Bash script, from a MinGW program, from an MSYS2 program? How are you passing paths to it? Are the paths in a file, on the command line, or in environment variables? If the paths are in arguments, did you try setting the "MSYS2_ARG_CONV_EXCL" environment variable to "-" before invoking Make? --David On Wed, Jun 23, 2021 at 7:23 AM Kacvinsky, Tom wrote: > Hi, > > I have found an issue - perhaps a user mistake - which I need to pass > Cygwin style paths to make. > So instead of c:/path/to/whatever, I need to use > /cygdrive/c/path/to/whatever. Is there a way > of forcing GNU make on MSYS2 + MinGW-w64 to honor paths of the form the > c:/path/to/whatever. > > FWIW, I am setting the PATH in a DOS shell first, and even tried escaping > the : with ^ - the escape > character for DOS command prompts (so c^:/). I've also tried the bash > escape character (so c\:/). > > No joy. > > Any pointers you may have would be appreciated. If you need more > information, please let me > know. > > Thanks and regards, > > Tom > > ___ > Mingw-w64-public mailing list > Mingw-w64-public@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/mingw-w64-public > ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] gcc x86_64-w64-mingw32 parses filenames mentioned on command line differently from filenames mentioned in @response files
When I use GCC on Windows, I generally use MSYS2, a MinGW version of CMake that I installed with its package manager, and I use the "MSYS Makefiles" CMake generator. If you're using a Cygwin or MSYS2 shell, you should be aware that those shells do some transformations to the command line to convert Unix-style paths to Windows-style paths whenever they are invoke a native Windows program, so that could explain the behavior you are getting. --David Grayson On Tue, Mar 9, 2021 at 12:52 PM Paul Ausbeck wrote: > gcc x86_64-w64-mingw32 can find and open absolute filenames or directory > names beginning /driveletter/ when they are mentioned directly on the > invoking command line. However, such filenames or include directories > mentioned in @response files aren't found. To be found, files or > directories mentioned in @response files must begin driveletter:. > > This behavior is particularly insidious as the command line behavior leads > one to expect that one could use the cmake Unix Makefile generator to build > with gcc x86_64-w64-mingw32 or i686-w64-mingw32 but only later finding that > @response files can't contain unix-like filenames. > > While there are special i686-w64 and x86_64-w64 versions of cmake > available, it would be quite a bit easier to set up a build environment if > these special versions of cmake weren't necessary. Less useful, but less > confusing, would be to enforce driveletter: absolute filename semantics on > the command line. In other words, filename parsing should be consistent > between the command line and @response files. > > > ___ > Mingw-w64-public mailing list > Mingw-w64-public@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/mingw-w64-public > ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Missing symbol strlwr_l
It seems like the MinGW-w64 headers provide a declaration for strlwr_l but
it doesn't really work. On MSDN I do not see anything about that function,
but I do see the similarly named function _strlwr_l.
_strlwr_l is defined in libmsvcrt.a, but it is not mentioned in the
MinGW-w64 headers. That seems like a bug that the maintainers would
probably accept a patch for.
If I provide an appropriate declaration for it, then I can use it in a
simple C program:
#include
#include
_SECIMP char *_strlwr_l(char *, _locale_t);
int main() {
char buffer[64] = "Tom\0\0";
_strlwr_l(buffer, 0);
printf("%s\n", buffer);
}
I hope this helps!
--David
On Thu, Jan 21, 2021 at 11:22 AM Kacvinsky, Tom
wrote:
> What library is strlwr_l supposed to come from? I have a lew of link
> errors due to missing wide
> char functions, but I have not been able to figure out which library to
> use. I am using the most
> up to date MSYS2 + the package for the GCC toolchain (GCC 10.2), with no
> modifications, but have had no joy. This happens with the i686 and x86_^4
> flavors of MinGW-w64.
>
> Thanks,
>
> Tom
>
> ___
> Mingw-w64-public mailing list
> Mingw-w64-public@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
>
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Posix path conversion ? and what about qt5 ?
This question would be more appropriate for the MSYS2 mailing list. The mingw-w64 project doesn't really do anything with Posix paths as far as I know. MSYS2 comes with a utility named cygpath that you can use. Run `cygpath -w NAME`. cygpath is a command-line utility in /usr/bin that you can run the same way you would run any other command-line utility. The output will be a Windows-style path corresponding to the NAME argument you passed. Also, if you're passing paths to your program on the command line or with environment variables in an MSYS2 shell, MSYS2 usually does a pretty good job at converting those to Windows-style paths. --David Grayson On Sat, Nov 28, 2020 at 10:47 AM D G wrote: > > Hi everybody, > > mingw64 qt5 is not posix path aware. > > /home/didier means according to it, C:\home\didier. > > I don't know how to convert it with the msys64 prefix, added. > > May you help me ... > > Thank you a lot > > cheers > Didier. > > ___ > Mingw-w64-public mailing list > Mingw-w64-public@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/mingw-w64-public > ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] cmake not creating directories on mingw64, works fine on linux.
My CMake file-installation needs are simpler than yours and I haven't
figured out how to make it truly portable but I have something that works.
I tell MSYS2 users to build/install the software by running these commands:
mkdir build
cd build
MSYS2_ARG_CONV_EXCL=- cmake .. -G"MSYS Makefiles"
-DCMAKE_INSTALL_PREFIX=$MINGW_PREFIX
make install DESTDIR=/
Here's an example project that uses those commands:
https://github.com/pololu/libusbp
--David Grayson
On Thu, Jan 23, 2020 at 3:30 PM David Mathog wrote:
> On 2020-01-23 15:08, David Grayson wrote:
> > Since CMake in MSYS2 is a native Windows program, if you ask it to make
> > /tmp, I expect it will make C:/tmp. Did that happen?
>
> Good call, that is exactly what happened!
>
> This is a problem (especially for a cross platform build environment)
> because the path usage within CMakeLists.txt seems to be inconsistent.
> While the file creation actions went into C:/tmp, after doing this:
>
> >>
> >> mkdir /tmp/testinstall
> >> mkdir /tmp/testinstall/bin
> >> mkdir /tmp/testinstall/man
> >> cmake -G "MSYS Makefiles" ..
> >> make
>
> the binaries and man files were all correctly deposited into
> /tmp/testinstall, not C:\tmp\testinstall. If this was a bash script I
> would know how to handle this, but within cmake I don't. Skipping all
> the compile stuff look at this subsection:
>
> SET(CMAKE_INSTALL_PREFIX "/tmp/testinstall")
> SET(CMAKE_RUNTIME_OUTPUT_DIRECTORY ${CMAKE_INSTALL_PREFIX}/bin)
> SET(MAN_INSTALL_DIR ${CMAKE_INSTALL_PREFIX}/man/man1)
>
> FILE(MAKE_DIRECTORY ${CMAKE_RUNTIME_OUTPUT_DIRECTORY})
> if (DO_MAN)
> FILE(GLOB MAN_FILES "${CMAKE_CURRENT_SOURCE_DIR}/*.1")
> FILE(MAKE_DIRECTORY ${MAN_INSTALL_DIR})
> #install man pages
> ADD_CUSTOM_TARGET(man ALL
> ${CMAKE_COMMAND} -E copy ${MAN_FILES} ${MAN_INSTALL_DIR}
> COMMENT "Copying all man pages")
> endif (DO_MAN)
>
> The MAKE_DIRECTORY for ${MAN_INSTALL_DIR} went to C:\tmp\testinstall\man
> and the CMAKE_COMMAND -E copy went to /tmp/testinstall/man. I think
> what is happening
> here is that when the CMAKE_COMMAND (or a compiler action) is done cmake
> actually spins out
> a bash session and runs the command line within that, so the usual
> cygwin to windows path conversions are performeds. But
> FILE(MAKE_DIRECTORY...) is internal to cmake and it probably does a
> mkdir() call directly, so the conversions are not made.
>
> Suggestions for making this portable
>
> Thanks,
>
> David Mathog
> mat...@caltech.edu
> Manager, Sequence Analysis Facility, Biology Division, Caltech
>
>
> ___
> Mingw-w64-public mailing list
> Mingw-w64-public@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
>
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] cmake not creating directories on mingw64, works fine on linux.
Since CMake in MSYS2 is a native Windows program, if you ask it to make
/tmp, I expect it will make C:/tmp. Did that happen?
--David
On Thu, Jan 23, 2020 at 2:55 PM David Mathog wrote:
> On 2020-01-23 14:15, David Mathog wrote:
> > The CMakeLists.txt file after my signature works correctly in linux
> > with:
> >
> > mkdir build
> > cd build
> > cmake ..
> > make
> >
> > but in mingw64 this:
> >
> > mkdir build
> > cd build
> > cmake -G "MSYS Makefiles" ..
> > make
> >
> > fails when it tries to link the first executable (which happens to be
> > pockmark.exe for some reason) because it has failed to create the
> > directories /tmp/testinstall and /tmp/testinstall/bin. That should
> > happen at this line:
> >
> > FILE(MAKE_DIRECTORY ${CMAKE_RUNTIME_OUTPUT_DIRECTORY})
>
> Ran on both platforms with extra flags:
>
> cmake --debug-output --trace-expand -S .. 2>&1 | tee /tmp/foo
>
> and there are no warnings or errors in the mingw64 one when it passes
> the relevant lines:
>
> C:/progs/msys64/home/david/drm_tools-1.1.32/CMakeLists.txt(46):
> FILE(MAKE_DIRECTORY /tmp/testinstall/bin )
> Called from:
> [1] C:/progs/msys64/home/david/drm_tools-1.1.32/CMakeLists.txt
> C:/progs/msys64/home/david/drm_tools-1.1.32/CMakeLists.txt(47):
> if(DO_MAN )
> Called from:
> [1] C:/progs/msys64/home/david/drm_tools-1.1.32/CMakeLists.txt
>
> it just silently fails to create those directories. Nor were there any
> issues apparent above that, it was 1:1 but with different paths and
> versions on the two platforms.
>
> Do this:
>
> mkdir /tmp/testinstall
> mkdir /tmp/testinstall/bin
> mkdir /tmp/testinstall/man
> cmake -G "MSYS Makefiles" ..
> make
>
> and it runs without any warnings or errors. The ONLY thing that fails
> are the
>FILE(MAKE_DIRECTORY...)
> lines in the CMakeLists.txt file.
>
> Is this just me or is that feature broken in this version of cmake???
>
> Thanks,
>
> David Mathog
> mat...@caltech.edu
> Manager, Sequence Analysis Facility, Biology Division, Caltech
>
>
> ___
> Mingw-w64-public mailing list
> Mingw-w64-public@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
>
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] path conversion in bash limitations
You could try cygpath: $ cygpath -w /tmp/infile1.txt C:\msys64\tmp\infile1.txt But that seems annoying. I might try using relative paths so no conversion is needed and your script can be cross-platform without much effort. You can use `cd` to navigate to a different directory before running the command. --David Grayson On Tue, Jan 7, 2020 at 4:16 PM David Mathog wrote: > In a mingw64 shell if one does something like: > > program -in /tmp/infile.txt -out /tmp/outfile.txt > > it will generally work because somewhere or other this will happen: > >/tmp/infile.txt -> C:\progs\msys64\tmp\infile.txt >/tmp/outfile.txt -> C:\progs\msys64\tmp\outfile.txt > > That this works so well most of the time makes me complacent. > Unfortunately it isn't a 100% thing. If a program accepts input which > consists of a comma delimited list of files it will fail miserably > because: > > program -in /tmp/infile1.txt,/tmp/infile2.txt -out /tmp/outfile.txt > > /tmp/infile1.txt -> C:\progs\msys64\tmp\infile1.txt > /tmp/infile2.txt (unchanged) > > and the second file will not open because when it hits the windows > pieces they do not know what that string means. > > Is there somewhere or other a wrapper function that works in MSYS2's > bash which one can apply to a command like this to force conversion? > Something along these lines: > > program -in FILES(/tmp/infile1.txt,/tmp/infile2.txt) -out > /tmp/outfile.txt > > or > > program -in FILE(/tmp/infile1.txt),FILE(/tmp/infile2.txt) -out > /tmp/outfile.txt > > Thanks, > > David Mathog > mat...@caltech.edu > Manager, Sequence Analysis Facility, Biology Division, Caltech > > > ___ > Mingw-w64-public mailing list > Mingw-w64-public@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/mingw-w64-public > ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] relocating Qt5 based program?
On Fri, Jan 3, 2020 at 3:23 PM David Mathog wrote: > Please define "next to". > "platforms" would be in the same directory as your executable, if I recall correctly. You could also try naming it "plugins" and you could also try putting copies of it in a bunch of different places. --David ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] relocating Qt5 based program?
On Fri, Jan 3, 2020 at 1:11 PM David Mathog wrote: > qt.qpa.plugin could not find the Qt platform plugin "windows" in "" > I've solved this type of error before without having to write a qt.conf file. Qt is looking for a DLL with a name that is something like qwindows.dll or qt5windows.dll. You can put that DLL in a directory named "platforms" next to the main executable so that Qt can find it. Of course, statically linking everything would be better if you can figure out how to do that. --David Grayson ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] libxml2 2.9.7 built a year ago, not now
Have you considered simply installing libxml2 by running this command? pacman -S mingw-w64-i686-libxml2 Also, make sure you are running MSYS2 via mingw32.exe, and that you have installed the proper GCC toolchain: pacman -S mingw-w64-i686-toolchain --David On Wed, Dec 11, 2019 at 1:51 PM David Mathog wrote: > > Trying to build libxml2 in MSYS2 mingw32. About a year ago using the > same commands 2.9.7 built without problems. Now neither 2.9.10 nor > 2.9.7 will build, both failing in the "python" part of the build. > After downloading and unpacking libxml2 2.9.10 (2.9.7 acts the same) > did: > > #in an MSYS2 mingw32 window > ./configure > make > > which failed. > > The python section wanted to include "crypt.h". Installed that with: >pacman -S libcrypt > but it still did not find it, because the file is in /usr/include rather > than /mingw32/include. It is looking for python includes in > /usr/include/python3.7m but changing that to python2.7 did not help. > > With "make V=1" found the compile line which was looking for "crypt.h" > and added to it "-I/usr/include". That got it past the crypt.h problem > but then it wanted "sys/select.h", which is I think an even bigger > problem. > > I didn't see an option for 2.9.10 like "--disable-libcrypt" or anything > like that. > > Anybody else run into this yet? > > This was after updating all of mingw32 with "pacman -Syu" (twice) > yesterday. So I think all of the Msys2/mingw32 pieces should be > current. > Everything was updated about a year ago too, before the last build. So > some combination of mingw32 and libxml2 changes in the last year seem to > have broken things. > > Thanks, > > David Mathog > mat...@caltech.edu > Manager, Sequence Analysis Facility, Biology Division, Caltech > > > ___ > Mingw-w64-public mailing list > Mingw-w64-public@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/mingw-w64-public ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Fwd: Mingw Build Errors
There used to be a halfway-decent mingw-w64 wiki page about how to build a cross-compiler, but I can't find it. Perhaps someone has already done the work to create a cross-compiler package for your Linux distribution. This StackOverflow question seems promising: https://unix.stackexchange.com/questions/327156/where-can-i-find-and-install-the-mingw-w64-packages-for-centos-7 I also have a personal project that you could use to build a cross-compiler on any Linux distribution, or you could just look at the build recipes in my project as a reference: https://github.com/DavidEGrayson/nixcrpkgs By the way, you're not going to be able to manually install all the MinGW headers and make sure they have the proper contents just by reading helpful configure script errors. You need an actual guide/recipes that tells you how to install those headers by running the appropriate commands. --David On Mon, Dec 2, 2019 at 4:49 PM Thomas Dineen wrote: > > Gentle People: > > I am getting the following configure error when I attempt to build > mingw-w64-crt: > Please show me the best or proper instructions for building a mingw > cross compiler on CentOS > with a target of Windows(X86 and i686). I am suffering with google > search overload with too many > opinions! > Full listing shown below: > > Error: > > Checking _mingw_mac.h usability... no > checking _mingw_mac.h presence... no > checking for _mingw_mac.h... no > configure: error: Please check if the mingw-w64 header set and the > build/host option are set properly. > > Full Listing: > > cd /home/tdineen/Mingw_Build_X86_11_2019/mingw-w64-v7.0.0/mingw-w64-crt > > Linux3% ./configure > --prefix=/home/tdineen/Mingw_Build_X86_11_2019/x86_64-w64-mingw32/sysroot > --host=x86_64-w64 mingw32 > -includedir=/home/tdineen/Mingw_Build_X86_11_2019/mingw-w64-v2.0.7/mingw-w64-crt/include > > checking for a BSD-compatible install... /usr/bin/install -c > checking whether build environment is sane... yes > checking for x86_64-w64-mingw32-strip... no > checking for strip... strip > checking for a thread-safe mkdir -p... /bin/mkdir -p > checking for gawk... gawk > checking whether make sets $(MAKE)... yes > checking whether make supports nested variables... yes > checking whether to enable maintainer-specific portions of Makefiles... no > checking build system type... x86_64-pc-linux-gnu > checking host system type... x86_64-w64-mingw32 > checking for sysroot... > /home/tdineen/Mingw_Build_X86_11_2019/x86_64-w64-mingw32/sysroot > checking for a sed that does not truncate output... /bin/sed > checking for gawk... (cached) gawk > checking for x86_64-w64-mingw32-gcc... no > checking for gcc... gcc > checking whether the C compiler works... yes > checking for C compiler default output file name... a.out > checking for suffix of executables... > checking whether we are cross compiling... no > checking for suffix of object files... o > checking whether we are using the GNU C compiler... yes > checking whether gcc accepts -g... yes > checking for gcc option to accept ISO C89... none needed > checking whether gcc understands -c and -o together... yes > checking for style of include used by make... GNU > checking dependency style of gcc... gcc3 > checking for x86_64-w64-mingw32-g++... no > checking for x86_64-w64-mingw32-c++... no > checking for x86_64-w64-mingw32-gpp... no > checking for x86_64-w64-mingw32-aCC... no > checking for x86_64-w64-mingw32-CC... no > checking for x86_64-w64-mingw32-cxx... no > checking for x86_64-w64-mingw32-cc++... no > checking for x86_64-w64-mingw32-cl.exe... no > checking for x86_64-w64-mingw32-FCC... no > checking for x86_64-w64-mingw32-KCC... no > checking for x86_64-w64-mingw32-RCC... no > checking for x86_64-w64-mingw32-xlC_r... no > checking for x86_64-w64-mingw32-xlC... no > checking for g++... g++ > checking whether we are using the GNU C++ compiler... yes > checking whether g++ accepts -g... yes > checking dependency style of g++... gcc3 > checking how to run the C preprocessor... gcc -E > checking for x86_64-w64-mingw32-ranlib... no > checking for ranlib... ranlib > checking for x86_64-w64-mingw32-dlltool... no > checking for dlltool... no > checking for x86_64-w64-mingw32-ar... no > checking for x86_64-w64-mingw32-lib... no > checking for x86_64-w64-mingw32-link... no > checking for ar... ar > checking the archiver (ar) interface... ar > checking dependency style of gcc... gcc3 > checking for x86_64-w64-mingw32-as... no > checking for as... as > checking whether to build a w32api package for Cygwin... no > checking whether to build the Win32 libraries... yes > checking whether to build the Win64 libraries... yes > checking whether to build the WinARM32 libraries... no > checking whether to build the WinARM64 libraries... no > checking whether to use genlib... no > checking whether to enable globbing... no > checking whether to enable private exports... no > checking whether to enable delay import libs... no > checking what to provide as libmsvcrt.a
Re: [Mingw-w64-public] PKGBUILD script for toolchain, still having GCC compile errors
It's not really a chicken and egg situation. You just need to convince GCC to be a cross-compiler hosted on the mingw-msvcrt environment and targeting the mingw-ucrt environment. Any libraries you build targeting ucrt (including mingw-w64's) would go in a directory like /mingw64-ucrt instead of /mingw64 to avoid confusion. When you build executables that are part of GCC, they would link to the UCRT. But that seems like an uncommon configuration and GCC might not understand it. I did a quick search for "ucrt" in the GCC 8.3.0 source code and I don't see anything about it except in libsanitizer. I'm not sure if you can somehow add "ucrt" to the triple that GCC uses to identify the system it's targeting (x86_64-w64-mingw32). There might be a lot of code in GCC that assumes that all MinGW environments are equal if their architectures are equal, so it might be hard to convince GCC that it is a cross-compiler. That makes me think it might actually be easier if the cross-compiler where hosted in the msys2/Cygwin runtime, or on Linux. Here's a project I made to make it easy to cross-compile for MinGW on Linux: https://github.com/DavidEGrayson/nixcrpkgs It has no support the UCRT, but since its scripts are small and simple, it might be easy to add it. (Right now it only takes 362 lines of scripts and 8 patches to build a cross-compiling toolchain with binutils, GCC 8, and mingw-w64.) --David On Thu, Apr 18, 2019 at 7:04 AM Kacvinsky, Tom wrote: > > > > > -Original Message- > > From: Kacvinsky, Tom > > Sent: Wednesday, April 17, 2019 12:39 PM > > To: mingw-w64-public@lists.sourceforge.net > > Subject: Re: [Mingw-w64-public] PKGBUILD script for toolchain, still having > > GCC compile errors > > > > > > > This is good stuff, thanks for the instructions. One question, though. I > > want > > mingw-w64-crt v6.0.0 support for UCRT> How did I modify the PKGBUILD > > script to get this support? While I am at it, I want winpthreads support > > and > > perhaps she instead of sjlj exception handling for libgnat. > > So I thought I'd change the configure options in PKGBUILD for the CRT to add > > --with-default-msvcrt=ucrt > > built and installed it. But now when building GCC, I get the following > > C:/msys64-redux/mingw64/lib/gcc/x86_64-w64-mingw32/8.3.0/adalib/libgnat.a(argv.o):(.rdata$.refptr.__imp__environ[.refptr.__imp__environ]+0x0): > undefined reference to `__imp__environ' > collect2.exe: error: ld returned 1 exit status > gnatlink: error when calling C:\msys64-redux\mingw64\bin\gcc.exe > gnatmake: *** link failed. > > This is not surprising since the GCC I have on the system contains a libgnat > that > uses the older MSVC runtime, which requires the _environ symbol. So I have a > chicken and egg situation here. > > Any way around this? > > Thanks, > > Tom > > ___ > Mingw-w64-public mailing list > Mingw-w64-public@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/mingw-w64-public ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] PKGBUILD script for toolchain, still having GCC compile errors
Oh yeah, another thing I was going to say is that `--prefix=/usr/local` looks very suspect to me. That directory is where all of the msys2 software lives. I assume you're trying to build a MinGW compiler, which itself is a MinGW (native Windows) program. --David On Tue, Apr 16, 2019 at 9:51 AM David Grayson wrote: > > That script specifies pkgver=8.3.0, so it builds GCC 8.3.0. > > The script is meant to be run in MSYS2, not Cygwin. You could try > following these instructions to build the GCC package with > makepkg-mingw and see if it works: > > https://github.com/msys2/msys2/wiki/Creating-Packages > > --David > > On Tue, Apr 16, 2019 at 5:43 AM Kacvinsky, Tom > wrote: > > > > I am looking at this script > > > > https://github.com/msys2/MINGW-packages/blob/master/mingw-w64-gcc/PKGBUILD > > > > It doesn't say which version of gcc this is for as far as I can tell, so > > perhaps it is generic. > > > > What I have found is that some of the patches don't seem to apply to GCC > > 8.3.0, at > > least when I apply them manually. > > > > Also, is this a Cygwin based script, or an msys2 based script? > > > > A reason why I ask is that I can't even get GCC 8.3.0 to build (whether > > with the new CRT, > > or not). IT fails to configure at stage2-bubble with not finding stdarg.h > > and limits.h, etc... > > I looked over the config log and the -I options don't seem correct for > > finding the headers. > > > > How I am configuring > > > > ../gcc-patched/configure --prefix=/usr/local --enable-languages=c,c++,ada > > --disable-multilib --disable-lto --host=x86_64-w64-mingw32 > > --with-native-system-header-dir=/mingw64/x86_64-w64-mingw32/include > > > > The error in stage2-bubble (for gcc) is this > > > > configure:5153: /home/vapkay/gcc-build/./prev-gcc/xg++ > > -B/home/vapkay/gcc-buil\ > > d/./prev-gcc/ -B/usr/local/x86_64-w64-mingw32/bin/ -nostdinc++ > > -B/home/vapkay/g\ > > cc-build/prev-x86_64-w64-mingw32/libstdc++-v3/src/.libs > > -B/home/vapkay/gcc-buil\ > > d/prev-x86_64-w64-mingw32/libstdc++-v3/libsupc++/.libs > > -I/home/vapkay/gcc-buil\ > > d/prev-x86_64-w64-mingw32/libstdc++-v3/include/x86_64-w64-mingw32 > > -I/home/vapk\ > > ay/gcc-build/prev-x86_64-w64-mingw32/libstdc++-v3/include > > -I/home/vapkay/gcc-p\ > > atched/libstdc++-v3/libsupc++ > > -L/home/vapkay/gcc-build/prev-x86_64-w64-mingw32/\ > > libstdc++-v3/src/.libs > > -L/home/vapkay/gcc-build/prev-x86_64-w64-mingw32/libstdc\ > > ++-v3/libsupc++/.libs -E conftest.cpp > > In file included from > > C:/msys64-redux/home/vapkay/gcc-build/prev-gcc/include-fi\ > > xed/syslimits.h:7, > > from > > C:/msys64-redux/home/vapkay/gcc-build/prev-gcc/include-fi\ > > xed/limits.h:34, > > from conftest.cpp:10: > > C:/msys64-redux/home/vapkay/gcc-build/prev-gcc/include-fixed/limits.h:194:61: > > e\ > > rror: no include path in which to search for limits.h > > > > There is no -I for finding these headers. Those headers exist, but not In > > the location > > the -I options specify. > > > > Any ideas? > > > > Thanks, > > > > Tom > > > > > > ___ > > Mingw-w64-public mailing list > > Mingw-w64-public@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/mingw-w64-public ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] PKGBUILD script for toolchain, still having GCC compile errors
That script specifies pkgver=8.3.0, so it builds GCC 8.3.0. The script is meant to be run in MSYS2, not Cygwin. You could try following these instructions to build the GCC package with makepkg-mingw and see if it works: https://github.com/msys2/msys2/wiki/Creating-Packages --David On Tue, Apr 16, 2019 at 5:43 AM Kacvinsky, Tom wrote: > > I am looking at this script > > https://github.com/msys2/MINGW-packages/blob/master/mingw-w64-gcc/PKGBUILD > > It doesn't say which version of gcc this is for as far as I can tell, so > perhaps it is generic. > > What I have found is that some of the patches don't seem to apply to GCC > 8.3.0, at > least when I apply them manually. > > Also, is this a Cygwin based script, or an msys2 based script? > > A reason why I ask is that I can't even get GCC 8.3.0 to build (whether with > the new CRT, > or not). IT fails to configure at stage2-bubble with not finding stdarg.h > and limits.h, etc... > I looked over the config log and the -I options don't seem correct for > finding the headers. > > How I am configuring > > ../gcc-patched/configure --prefix=/usr/local --enable-languages=c,c++,ada > --disable-multilib --disable-lto --host=x86_64-w64-mingw32 > --with-native-system-header-dir=/mingw64/x86_64-w64-mingw32/include > > The error in stage2-bubble (for gcc) is this > > configure:5153: /home/vapkay/gcc-build/./prev-gcc/xg++ > -B/home/vapkay/gcc-buil\ > d/./prev-gcc/ -B/usr/local/x86_64-w64-mingw32/bin/ -nostdinc++ > -B/home/vapkay/g\ > cc-build/prev-x86_64-w64-mingw32/libstdc++-v3/src/.libs > -B/home/vapkay/gcc-buil\ > d/prev-x86_64-w64-mingw32/libstdc++-v3/libsupc++/.libs > -I/home/vapkay/gcc-buil\ > d/prev-x86_64-w64-mingw32/libstdc++-v3/include/x86_64-w64-mingw32 > -I/home/vapk\ > ay/gcc-build/prev-x86_64-w64-mingw32/libstdc++-v3/include > -I/home/vapkay/gcc-p\ > atched/libstdc++-v3/libsupc++ > -L/home/vapkay/gcc-build/prev-x86_64-w64-mingw32/\ > libstdc++-v3/src/.libs > -L/home/vapkay/gcc-build/prev-x86_64-w64-mingw32/libstdc\ > ++-v3/libsupc++/.libs -E conftest.cpp > In file included from > C:/msys64-redux/home/vapkay/gcc-build/prev-gcc/include-fi\ > xed/syslimits.h:7, > from > C:/msys64-redux/home/vapkay/gcc-build/prev-gcc/include-fi\ > xed/limits.h:34, > from conftest.cpp:10: > C:/msys64-redux/home/vapkay/gcc-build/prev-gcc/include-fixed/limits.h:194:61: > e\ > rror: no include path in which to search for limits.h > > There is no -I for finding these headers. Those headers exist, but not In > the location > the -I options specify. > > Any ideas? > > Thanks, > > Tom > > > ___ > Mingw-w64-public mailing list > Mingw-w64-public@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/mingw-w64-public ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Issue with documentation for building CRT and GCC
In my nixcrpkgs project, I never had to use "--disable-multilib". I just use "--host=x86_64-w64-mingw32" or "--host=i686-w64-mingw32" and it seems to only build one library. Also I don't have a 32-bit GCC on my path when building a 64-bit mingw-w64, so there would be no way for it to build any 32-bit libraries. Regarding the mingw prefix, I patch GCC's gcc/config/i386/mingw32.h file so it doesn't use it: https://github.com/DavidEGrayson/nixcrpkgs/blob/a408b5c/mingw-w64/gcc/mingw-search-paths.patch There's also another patch I need to get the header paths to be correct: https://github.com/DavidEGrayson/nixcrpkgs/blob/a408b5c/mingw-w64/gcc/cppdefault.patch --David On Thu, Apr 4, 2019 at 10:19 AM Kacvinsky, Tom wrote: > > I am using > > https://sourceforge.net/p/mingw-w64/wiki2/Cross%20Win32%20and%20Win64%20compiler/ > > In there, it says to use --disable-multilib if I do not want 32 and 64-bit > support, only the native > mingw-w64 architecture. Despite adding that to the configure options, lib32 > is still built. I'd > have to say there is an error in the documentation, or the configure script > is not working as > expected. > > I added --disable-multiarch and that did not work for the mingw-w64-crt. I > guess the only thing > that will work is --disable-lib32. > > Also of note, following the instructions for building just the GCC ompiler > (make all-gcc), I get > an error that the headers to be fixed are expected to be in /mingw. > In my case, I > did the Windows equivalent of > > ln -s /usr/local/x86_64-w64-mingw32 /usr/local/mingw > > because I had used /usr/local as my prefix. But, the GCC compile still > complained about the > header missing, and expects them in /mingw/include. So I copied the headers > there and it > worked. > > Maybe this is why the gcc that comes from msys64 package > mingw-w64-x86+64-toolchain is > configured with " > --with-native-system-header-dir=/mingw64/x86_64-w64-mingw32/include", > and I would just have to modify my configure to use /usr/local/ > x86_64-w64-mingw32/include > instead > > > ___ > Mingw-w64-public mailing list > Mingw-w64-public@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/mingw-w64-public ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] DLL produced by Mingw-w64 can't be loaded
Your experience matches mine: the Cygwin ldd utility does not work properly
with MinGW DLLs and prints a bunch of question marks. There is an ntldd
utility you can use instead. If it's not on your path already, I'm not
sure the best way to obtain it. I just use MSYS2, because it's basically a
fork of Cygwin that makes it easy to install MinGW compilers and all the
other open source utilities you would need to build software on Linux,
including ntldd.
--David
On Wed, Mar 6, 2019 at 4:44 AM Matthias Apitz wrote:
>
>
> Hello,
>
> We have some bigger Java applications running as fat clients on
> Windows PC. These clients are using some Windows services, for example for
> printing, through some DLL written in C++ many years ago and then only
> compiled as 32-bit DLL. Moving forward to OpenJDK 1.8 with a 64-bit JRE
> we now struggle with compiling these DLL to a 64-bit version and I proposed
> here in my company to give mingw-w64 a try. I installed the recent version
> of mingw-w64 into Cygwin and can produce the 64-bit DLL this way (more or
> less without going through all details):
>
> LANG=C export LANG
> CC=/usr/bin/x86_64-w64-mingw32-gcc.exe
> DLL=SiPrinter_x64.dll
>
> for i in *.cpp; do
> ${CC} -I/home/apitzm/jdk1.8.0_202/include
> -I/home/apitzm/jdk1.8.0_202/include/win32 -c ${i}
> done
>
> ${CC} -shared -L/usr/x86_64-w64-mingw32/sys-root/mingw/lib -o ${DLL} *.o
> -lwinspool -lstdc++ -lgdi32 -lcomdlg32
>
> The resulting SiPrinter_x64.dll causes in Java a class loader exception
> because
> there is someting missing:
>
> $ ldd SiPrinter_x64.dll
> ntdll.dll => /cygdrive/c/Windows/SYSTEM32/ntdll.dll (0x7789)
> kernel32.dll => /cygdrive/c/Windows/system32/kernel32.dll
> (0x)
> KERNELBASE.dll => /cygdrive/c/Windows/system32/KERNELBASE.dll
> (0x7fefd66)
> ??? => ??? (0x6964)
> ^^^
>
> and the loader exception is:
>
> java.lang.UnsatisfiedLinkError:
> C:\Users\apitzm\vb\SunRise\SRv70\Ausleih-Client\bin\SiPrinter.dll: Can't
> find dependent libraries
> at java.lang.ClassLoader$NativeLibrary.load(Native Method)
> at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1941)
> at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1857)
> at java.lang.Runtime.loadLibrary0(Runtime.java:870)
> at java.lang.System.loadLibrary(System.java:1122)
> at sisis.util.Printer.(Printer.java:67)
> at sisis.lib.drucker.GDIDrucker.(GDIDrucker.java:132)
> at sisis.app.btc.BTCApp.initDrucker(BTCApp.java:3419)
> at sisis.app.btc.BTCApp.(BTCApp.java:2840)
> at sisis.app.btc.BTCApp.main(BTCApp.java:1865)
> Exception: System.loadLibrary()
>
> What is missing in the DLL, also seen as a problem by the ldd-command?
>
> Thanks
>
> matthias
> --
> Matthias Apitz, ✉ g...@unixarea.de, http://www.unixarea.de/
> +49-176-38902045
> Public GnuPG key: http://www.unixarea.de/key.pub
>
>
> ___
> Mingw-w64-public mailing list
> Mingw-w64-public@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
>
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Mingw-w64 builds twice.
For what it's worth, I just tried the latest version of mingw-w64 and I am not seeing any issue with the CRT getting compiled again when `make install` is run. My build scripts are here: https://github.com/DavidEGrayson/nixcrpkgs/tree/master/mingw-w64 The basic procedure is: 1) Before any mingw-w64 GCC is available, install the headers with: mingw-w64-headers/configure, make, make install 2) Build a temporary mingw-w64 GCC and install it. 3) Build the CRT and the headers using the top-level configure script and install them: ./configure, make, make install 4) Build a final mingw-w64 GCC and install it. I don't think I totally made up this procedure, I got it by looking at other people's work. --David On Tue, Oct 23, 2018 at 4:01 AM James Larrowe wrote: > No, but I did do something similar. I first installed the headers, like you > suggested, but then I created a seperate build directory (build) in the > root tree. I then proceeded to compile the crt, tools, and libraries. While > in the build directory, `make install` still ran the compilation for > mingw-w64-crt. > > On Mon, Oct 22, 2018 at 10:18 PM Liu Hao wrote: > > > 在 2018/10/23 5:15, James Larrowe 写道: > > > Mingw-w64 (Latest git version), builds twice: once during `make`, and > > once > > > during `make install`. It seems to be that it only builds mingw-w64-crt > > > twice. Any suggestions? > > > > > > > Did you run 'configure' followed by 'make' from _the project root > > directory_ ? > > > > Don't do that. The correct steps to build mingw-w64 from source are: > > > > 1. CD into 'mingw-w64-headers'. > > 2. Run `./configure` with proper options, followed by `make`. > > 3. Run `make install`. This installs new headers into the usual > >directory. > > 4. CD back into '../mingw-w64-crt'. > > 5. Run `./configure` with proper options, followed by `make`. > >Here you might have already known why step 3 is essential: The > >new headers have to be installed for consumption by your compiler > >during this process. > > 6. Run `make install`. This installs new libraries and CRT object > >files into the usual directory. > > > > > > -- > > Best regards, > > LH_Mouse > > > > ___ > > Mingw-w64-public mailing list > > Mingw-w64-public@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/mingw-w64-public > > > > ___ > Mingw-w64-public mailing list > Mingw-w64-public@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/mingw-w64-public > ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [PATCH] crt: Add "volatile" to all inline assembly snippets under math
Sorry to both of you. My brain just messed up there and I only realized when it was too late. --David On Mon, Mar 12, 2018 at 1:37 PM, Martell Malone wrote: > Just so you are aware that is Martin not Martell. > Not sure if that was just an autocorrect or a typo but Martin is the one > doing this work here. > > On Mon 12 Mar 2018 at 12:20, Martin Storsjö wrote: > >> On Mon, 12 Mar 2018, Martin Storsjö wrote: >> >> > On Sun, 11 Mar 2018, David Grayson wrote: >> > >> >> Martell, did you send a bug report to clang too? That seems like a >> >> serious bug for them to have. >> > >> > I didn't send one yet, but I will. It's curious as it seems to work fine >> for >> > x86_64 though. >> > >> >> Also, "asm volatile" statements cannot be removed, reordered or >> >> cached, right? It seems like a bad idea to hamper GCC's optimizations >> >> and performance as a workaround for a clang bug. >> > >> > Well, if it'd be inline functions in a header, I'd be inclined to agree. >> All >> > of these are in non-inline functions (e.g. like the sqrt function, where >> you >> > expect it to always produce one "fsqrt" instruction), so I don't expect >> any >> > losses there. >> > >> > However, I do see a few instances of similar inline asm snippets in >> math.h, >> > and there, volatile indeed would be suboptimal. >> >> Actually, it seems like volatile already is specified in all the >> corresponding cases in math.h. >> >> // Martin >> >> -- >> Check out the vibrant tech community on one of the world's most >> engaging tech sites, Slashdot.org! http://sdm.link/slashdot >> ___ >> Mingw-w64-public mailing list >> Mingw-w64-public@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public >> > -- > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > ___ > Mingw-w64-public mailing list > Mingw-w64-public@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/mingw-w64-public -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [PATCH] crt: Add "volatile" to all inline assembly snippets under math
Martell, did you send a bug report to clang too? That seems like a serious bug for them to have. Also, "asm volatile" statements cannot be removed, reordered or cached, right? It seems like a bad idea to hamper GCC's optimizations and performance as a workaround for a clang bug. --David On Sun, Mar 11, 2018 at 3:16 PM, Martin Storsjö wrote: > On Sun, 11 Mar 2018, Kai Tietz via Mingw-w64-public wrote: > >> Patch is ok. > > > Thanks, pushed. > > // Martin > > > -- > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > ___ > Mingw-w64-public mailing list > Mingw-w64-public@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/mingw-w64-public -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] genlib 0 can not compile
Since the first error is saying uint16_t is undefined, did you try adding "#include " at the top of genlib.c? --David Grayson On Mar 11, 2018 5:06 AM, wrote: > For some strange reason, I'm getting these errors when compiling the tools > for MINGW-W64: > > > > > > $ makepkg-mingw -f > > ==> Making package: mingw-w64-tools-git 6.0.0.5114.b633824e-1 (Sun, Mar 11, > 2018 7:41:04 AM) > > ==> Checking runtime dependencies... > > ==> Checking buildtime dependencies... > > ==> Retrieving sources... > > -> Updating mingw-w64 git repo... > > Fetching origin > > -> Found fix-warnings.patch > > ==> Validating source files with sha256sums... > > mingw-w64 ... Skipped > > fix-warnings.patch ... Passed > > ==> Extracting sources... > > -> Creating working copy of mingw-w64 git repo... > > Cloning into 'mingw-w64'... > > done. > > Checking out files: 100% (5367/5367), done. > > ==> Starting prepare()... > > ==> Starting pkgver()... > > ==> Removing existing $pkgdir/ directory... > > ==> Starting build()... > > Building gendef ... > > configure: loading site script /etc/config.site > > checking for a BSD-compatible install... /usr/bin/install -c > > checking whether build environment is sane... yes > > checking for a thread-safe mkdir -p... /usr/bin/mkdir -p > > checking for gawk... gawk > > checking whether make sets $(MAKE)... yes > > checking whether make supports nested variables... yes > > checking whether to enable maintainer-specific portions of Makefiles... no > > checking build system type... x86_64-w64-mingw32 > > checking host system type... x86_64-w64-mingw32 > > checking for x86_64-w64-mingw32-gcc... x86_64-w64-mingw32-gcc > > checking whether the C compiler works... yes > > checking for C compiler default output file name... a.exe > > checking for suffix of executables... .exe > > checking whether we are cross compiling... no > > checking for suffix of object files... o > > checking whether we are using the GNU C compiler... yes > > checking whether x86_64-w64-mingw32-gcc accepts -g... yes > > checking for x86_64-w64-mingw32-gcc option to accept ISO C89... none needed > > checking whether x86_64-w64-mingw32-gcc understands -c and -o together... > yes > > checking for style of include used by make... GNU > > checking dependency style of x86_64-w64-mingw32-gcc... gcc3 > > checking how to run the C preprocessor... x86_64-w64-mingw32-gcc -E > > checking for grep that handles long lines and -e... /usr/bin/grep > > checking for egrep... /usr/bin/grep -E > > checking for ANSI C header files... yes > > checking for sys/types.h... yes > > checking for sys/stat.h... yes > > checking for stdlib.h... yes > > checking for string.h... yes > > checking for memory.h... yes > > checking for strings.h... yes > > checking for inttypes.h... yes > > checking for stdint.h... yes > > checking for unistd.h... yes > > checking for inttypes.h... (cached) yes > > checking for memory.h... (cached) yes > > checking for stdint.h... (cached) yes > > checking for stdlib.h... (cached) yes > > checking for string.h... (cached) yes > > checking for int32_t... yes > > checking for size_t... yes > > checking for uint16_t... yes > > checking for uint32_t... yes > > checking for uint64_t... yes > > checking for uint8_t... yes > > checking for memset... yes > > checking for strdup... yes > > checking for strrchr... yes > > checking for strlwr... yes > > checking whether to build gendef with libmangle... yes > > checking libmangle.h usability... yes > > checking libmangle.h presence... yes > > checking for libmangle.h... yes > > checking for libmangle_print_decl in -lmangle... yes > > checking that generated files are newer than configure... done > > configure: creating ./config.status > > config.status: creating Makefile > > config.status: creating config.h > > config.status: executing depfiles commands > > make all-am > > make[1]: Entering directory > '/home/jpmugaas/exp/mingw-w64-tools-git/src/x86_64-w64-mingw32-gendef' > > x86_64-w64-mingw32-gcc -DHAVE_CONFIG_H -I. > -I/home/jpmugaas/exp/mingw-w64-tools-git/src/mingw-w64/ > mingw-w64-tools/gende > f -I/mingw64/include -D_FORTIFY_SOURCE=2 -D__USE_MINGW_ANSI_STDIO=1 > -Werror -Wall -W -march=x86-64 -mtune=generic -O2 -pipe -MT > src/gendef-gendef.o -MD -MP -MF src/.deps/gendef-gendef.Tpo -c -o > src/gendef-gendef.o `test -f 'src/gendef.c' || ec
Re: [Mingw-w64-public] Missing header SearchAPI.h in Thunderbird cross-compile using mingw-w64
You can look at the header files in the Windows SDK as a reference, but don't directly copy anything from there. Email the patch to this list. Use a .txt extension for the patch so that Sourceforge does not filter out your attachment. You can look in the list archives to see examples of other patches that added header files. Your patch will be rejected if it is not "complete" (i.e. providing header file that contains all the features of the equivalent Microsoft header file). You will need to change the include statement in Thunderbird to use lowercase letters because all the mingw-w64 headers have lowercase names. I like to generate patches by cloning the git repository, editing some stuff, and then running "git diff > patch.txt". Since you're adding a file I guess you need to actually run "git add searchapi.h" and then "git diff --cached > patch.txt". The maintainers might prefer it if you make a commit and use "git format-patch" though, because then your name and commit message will be included in the patch, so there is less data for them to enter. --David On Thu, Mar 1, 2018 at 10:23 AM, Sukhbir Singh wrote: > Hi, > > I am trying to build Thunderbird for Windows on Linux using mingw-w64. (For > the specifics, I am building comm-esr52 THUNDERBIRD_52_6_0_RELEASE tag.) There > seems to be a missing header in mingw-w64, SearchAPI.h > > mail/components/search/nsMailWinSearchHelper.cpp:17:23: fatal error: > SearchAPI.h: No such file or directory > > Is there any documentation on adding or requesting headers to be included in > mingw-w64 (like for example, where to get the headers from) since there are > multiple headers missing for the Thunderbird build and I would like to add > them following the proper steps. > > -- > Sukhbir > > -- > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > ___ > Mingw-w64-public mailing list > Mingw-w64-public@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/mingw-w64-public -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] New bug fix from v5.x release soon
The mingw-w64 project has some documentation about how to build a mingw-w64 GCC compiler: https://sourceforge.net/p/mingw-w64/wiki2/Cross%20Win32%20and%20Win64%20compiler/ https://github.com/mirror/mingw-w64/tree/master/mingw-w64-doc/howto-build Or you could use MSYS2 and start with the build scripts here: https://github.com/Alexpux/MINGW-packages/tree/master/mingw-w64-crt-git Personally, I like my setup using Nix better, since I can build complex chains of software without having to remember the right order to build everything: https://github.com/DavidEGrayson/nixcrpkgs --David On Thu, Oct 26, 2017 at 5:27 PM, wrote: > -Original Message- From: Liu Hao > Sent: Thursday, October 26, 2017 11:51 PM > To: mingw-w64-public@lists.sourceforge.net ; sisyph...@optusnet.com.au > Cc: JonY > Subject: Re: [Mingw-w64-public] New bug fix from v5.x release soon > >> The attached patch should fix the problem. This is a quick fix and I don't >> have time to test it, please test so we can push this patch before this >> release. > > > Is there a link that will tell me specifically what I need to do - ie what > to download and patch, and what toolchain I should use to build it ? > I haven't actually built this stuff before. > > > Cheers, > Rob > > > > > -- > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > ___ > Mingw-w64-public mailing list > Mingw-w64-public@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/mingw-w64-public -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Devpkey.h
Oftentimes there are things missing from the mingw-w64 headers and what you can do is make a patch that fixes it and submit the patch on this mailing list (see the archives for examples). Usually it's not an intellectual property issue. --David On Tue, Oct 3, 2017 at 1:04 PM, John Warburton wrote: > Good evening, > > Today, in the usual daily compilation of a number of multimedia > utilities, I tried to compile the latest GitHub edition of > OpenCL-ICD-Loader, which is to be found here: > > https://github.com/KhronosGroup/OpenCL-ICD-Loader > > Unfortunately, a commit made today to that project seemed to require a > rather fuller version of Devpkey.h (devpkey.h) than exists in the > mingw-w64 project. > > In particular, a number of missing definitions were picked up, including: > > DEVPKEY_Device_ClassGuid > > ...which does appear in the ReactOS version of Devpkey.h > > I am very new to this, and wondered if there is way around this > problem? Or is there an intellectual property issue that is currently > unrespolved? Either way, my compilation is fixed by reverting to the > OpenCL-ICD-Loader tree before today's commit. > > Here is the original error message. Thank you for looking at this! > JW > > [ 38%] Building C object > test/driver_stub/CMakeFiles/OpenCLDriverStub.dir/icd.c.obj > /root/src/MultimediaTools-mingw-w64/sandbox/x86_64/OpenCL-ICD-Loader/icd_windows.c: > In function 'khrIcdOsVendorsEnumerateOnce': > /root/src/MultimediaTools-mingw-w64/sandbox/x86_64/OpenCL-ICD-Loader/icd_windows.c:135:5: > warning: implicit declaration of function 'InitOnceExecuteOnce' > [-Wimplicit-function-declaration] > InitOnceExecuteOnce(&initialized, khrIcdOsVendorsEnumerate, NULL, NULL); > ^~~ > /root/src/MultimediaTools-mingw-w64/sandbox/x86_64/OpenCL-ICD-Loader/icd_windows_hkr.c: > In function 'khrIcdOsVendorsEnumerateHKR': > /root/src/MultimediaTools-mingw-w64/sandbox/x86_64/OpenCL-ICD-Loader/icd_windows_hkr.c:212:21: > error: 'CM_GETIDLIST_FILTER_CLASS' undeclared (first use in this > function); did you mean 'CM_GETIDLIST_FILTER_BITS'? > ULONG ulFlags = CM_GETIDLIST_FILTER_CLASS | > ^ > CM_GETIDLIST_FILTER_BITS > /root/src/MultimediaTools-mingw-w64/sandbox/x86_64/OpenCL-ICD-Loader/icd_windows_hkr.c:212:21: > note: each undeclared identifier is reported only once for each > function it appears in > /root/src/MultimediaTools-mingw-w64/sandbox/x86_64/OpenCL-ICD-Loader/icd_windows_hkr.c:213:21: > error: 'CM_GETIDLIST_FILTER_PRESENT' undeclared (first use in this > function); did you mean 'CM_GETIDLIST_FILTER_CLASS'? > CM_GETIDLIST_FILTER_PRESENT; > ^~~ > CM_GETIDLIST_FILTER_CLASS > /root/src/MultimediaTools-mingw-w64/sandbox/x86_64/OpenCL-ICD-Loader/icd_windows_hkr.c:273:9: > error: unknown type name 'DEVPROPTYPE'; did you mean 'EPROTOTYPE'? > DEVPROPTYPE devpropType; > ^~~ > EPROTOTYPE > /root/src/MultimediaTools-mingw-w64/sandbox/x86_64/OpenCL-ICD-Loader/icd_windows_hkr.c:336:23: > warning: implicit declaration of function 'CM_Get_DevNode_Property > '; did you mean 'CM_Set_DevNode_Problem'? [-Wimplicit-function-declaration] > ret = CM_Get_DevNode_PropertyW( >^~~~ >CM_Set_DevNode_Problem > [ 42%] Linking C shared library ../../bin/libOpenCLDriverStub.dll > /root/src/MultimediaTools-mingw-w64/sandbox/x86_64/OpenCL-ICD-Loader/icd_windows_hkr.c:338:22: > error: 'DEVPKEY_Device_ClassGuid' undeclared (first use in this > function) > &DEVPKEY_Device_ClassGuid, > ^~~~ > CMakeFiles/OpenCL.dir/build.make:138: recipe for target > 'CMakeFiles/OpenCL.dir/icd_windows_hkr.c.obj' failed > make[2]: *** [CMakeFiles/OpenCL.dir/icd_windows_hkr.c.obj] Error 1 > make[2]: *** Waiting for unfinished jobs > [ 42%] Built target OpenCLDriverStub > CMakeFiles/Makefile2:67: recipe for target 'CMakeFiles/OpenCL.dir/all' failed > make[1]: *** [CMakeFiles/OpenCL.dir/all] Error 2 > Makefile:94: recipe for target 'all' failed > make: *** [all] Error 2 > Build failure. Please see error messages above. > > -- > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > ___ > Mingw-w64-public mailing list > Mingw-w64-public@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/mingw-w64-public -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Mingw-w64-public mailing list Mingw-w64-publi
Re: [Mingw-w64-public] [PATCH] Handle __CTOR_LIST__ for clang
Microsoft just published an article about this kind of thing: https://blogs.msdn.microsoft.com/oldnewthing/20170927-00/?p=97095 It seems that casting pointers to uintptr_t before comparing them would probably be safe. --David Grayson On Sat, Aug 5, 2017 at 12:44 PM, David Grayson wrote: > What I meant is that if GCC's optimizer ever figures out that we are > comparing pointers that came from two different memory objects, it > would know we are doing undefined behavior and would have a license to > do whatever it wants, including removing that code. The way the loop > is written right now is probably safer than anything that uses a > symbol at the end of the constructors. > > --David > > On Sat, Aug 5, 2017 at 11:52 AM, Martell Malone > wrote: >>> >>> I think Martell's last patch would have worked but it's not as safe as >>> I would like it to be. I think the constructor and destructor lists >> >> should not be defined in gccmain.c where they are used, because then >>> the compiler optimizer might start to get smart and stop optimizing >>> things in a bad way. >> >> That won't happen, this is what the attribute __used__ is for. >> The issue I have is about casting in a clean way. >> I also don't see the point in iterating through a list to get to the end >> and then navigating back through it again if you have a pointer to the last >> element. >> >>> >>> Also, I think we should add new symbols so there is no potential for a >>> clash with the symbols defined by the linker script in binutils. >> >> As I said in a previous email this would be one way to solve it yes. >> Here is what I said >>> This would mean that programs linked with LD would have an extra 2 >> pointers in the table but it should be fine otherwise. >> I would be cleaner and better to change the linker script though. >> >> On Sat, Aug 5, 2017 at 6:15 PM, David Grayson >> wrote: >> >>> Oops, here is the patch. >>> >>> On Sat, Aug 5, 2017 at 10:14 AM, David Grayson >>> wrote: >>> > I think Martell's last patch would have worked but it's not as safe as >>> > I would like it to be. I think the constructor and destructor lists >>> > should not be defined in gccmain.c where they are used, because then >>> > the compiler optimizer might start to get smart and stop optimizing >>> > things in a bad way. The kind of pointer arithmetic we're doing would >>> > be undefined behavior since we're intentionally getting a pointer to >>> > an object and then reading past the end of that object. >>> > >>> > Also, I think we should add new symbols so there is no potential for a >>> > clash with the symbols defined by the linker script in binutils. >>> > >>> > So, attached to this email is a patch that worked for me (I was able >>> > to compile and run a Qt Widgets application). I'm not entirely sure >>> > it would be a good patch to use though, since I'm not sure how GCC >>> > picks names for its global constructor and destructor sections, and >>> > how it sorts those names, so I'm not sure that the symbols we are >>> > defining would really be in the right place. >>> > >>> > --David Grayson >>> > >>> > On Sat, Aug 5, 2017 at 4:45 AM, Martell Malone >>> wrote: >>> >> Hey David, >>> >> >>> >> >>> >>> Your binutils patch did not apply cleanly to binutils-2.27 but I got >>> >>> it to work. It looks pretty dangerous to me because you removed the >>> >>> lines for keeping the .dtors, .dtor, .ctors, and .ctor sections. And >>> >>> you're using .ctors and .dtors in your other patch, and other code >>> >>> might use them too I suppose. >>> >> >>> >> >>> >> It applies cleanly to HEAD. >>> >> I changed to so that all it does is SORT the ctors and dtors sections. >>> >> Someone would have to confirm though. >>> >> >>> >> Maybe crtexe.c is not linked into shared libraries since they are not >>> EXEs. >>> >> >>> >> That is exactly what happened there crtdll.c is used instead. >>> >> Here is an updated patch which also applies to crtdll.c >>> >> >>> >> Also the only reason I am not putting it into gccmain.c is because I am >>> >> having problems wit
Re: [Mingw-w64-public] How to build the GCC cross-compiler?
Zebedia: Something is very wrong if the mingw headers for your cross compiler are installed directly in /usr/local/include on your Linux machine. Since those headers don't apply to software compiled for your Linux machine, they should be in a directory named something like i386-w64-mingw32. Now look at the error you posted. I'm not sure what program you were trying to configure, but clearly it is wrong to try to use "gcc" (which would be your Linux machine's native GCC, used to build Linux programs) with the MinGW headers (which are meant for native Windows software). That's why _mingw.h is complaining: you're trying to use it with the wrong compiler. If you're interested in cross-compiling from Linux to Windows, you might want to look at my Nixcrpkgs project, since I've already figured out a lot of the basic issues and you can reproduce my results reliably by just running a few commands: https://github.com/DavidEGrayson/nixcrpkgs --David Grayson On Wed, Aug 23, 2017 at 1:59 PM, Zebediah Figura wrote: > Hello, > > I am interested in implementing, or helping to implement, support for 16-bit > code and NE executables in mingw. > > I am trying to build the gcc cross-compiler (i386-w64-mingw32-gcc) in > accordance with the instructions at > https://sourceforge.net/p/mingw-w64/wiki2/Cross%20Win32%20and%20Win64%20compiler/ > but I run into an error configuring gcc: > > configure:5564: checking for the correct version of gmp.h > configure:5584: gcc -c -g -O2 conftest.c >&5 > In file included from /usr/local/include/crtdefs.h:10:0, > from /usr/local/include/limits.h:6, > from /usr/include/gmp.h:56, > from conftest.c:10: > /usr/local/include/_mingw.h:264:2: error: #error Only Win32 target is > supported! > > I built binutils and the headers for multilib, so I do not understand why I > am encountering this error. Can anyone help with this problem? > > Thanks, > Zeb > > > -- > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > ___ > Mingw-w64-public mailing list > Mingw-w64-public@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/mingw-w64-public -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [PATCH] Handle __CTOR_LIST__ for clang
Martell: OK, I looked at that link briefly. I think I understand what you're worried about here: the markers that we have at the beginning and end of our constructor/destructor sections might be removed by the linker of clang or GCC if it is determined that no code is actually referencing those variables. Yes, that could be a problem. The "used" attribute will probably take care of that, as long as something in the same source file is referenced. That is different from what I was worried about with the undefined behavior of comparing pointers from two different objects, but it is also a good thing to be worried about. --David On Wed, Aug 23, 2017 at 9:14 AM, Martell Malone wrote: > Hey David, > > I came across this today which might be of interest to our discussion, > while it is not related directly to the problem you mentioned it is similar. > https://reviews.llvm.org/D37059 > I will follow up with a patch for binutils to add __CTOR_END__ and > __DTOR_END__ but it is interesting to note. > > Martin we might have to add an exception in LLD for the 4 variables being > optimised out for the COFF linker with LTO. > (This is because there is no such thing as linker scripts for COFF) > > Best, > Martell > > On Tue, Aug 22, 2017 at 9:23 PM, Martin Storsjö wrote: > >> On Tue, 22 Aug 2017, Martell Malone wrote: >> >> pushed to master. >>> >> >> Fantastic, thanks! >> >> >> // Martin >> >> >> -- >> Check out the vibrant tech community on one of the world's most >> engaging tech sites, Slashdot.org! http://sdm.link/slashdot >> ___ >> Mingw-w64-public mailing list >> Mingw-w64-public@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public >> > -- > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > ___ > Mingw-w64-public mailing list > Mingw-w64-public@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/mingw-w64-public -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [PATCH] Handle __CTOR_LIST__ for clang
On Fri, Aug 18, 2017 at 12:26 PM, Martin Storsjö wrote: > Yup, that resolves the concern. > > As long as you just use one or the other of *_LIST__ or *_END__ in each > function and use the sentinel values instead of comparing the pointers, it > should be fine. Otherwise the compiler is free to regard the comparison as > nonsense. > > // Martin I'm not so sure; a normal C struct or array would never have a global symbol defined in the middle or at the end, so a smart compiler might some day assume that if you take a symbol and decrement it, it's an invalid pointer. I don't really want to argue much more than that, and I don't have a specific thing to point to in the C standard. --David -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [PATCH] Handle __CTOR_LIST__ for clang
Thanks for the explanation of the binutils bug, Martell.
Also, your latest patch has bad newlines inserted by GMail again. It
might actually be better to use GMail's HTML mode, or just use an
attachment with a .txt extension (not .patch).
--David
On Fri, Aug 18, 2017 at 12:05 PM, Martell Malone
wrote:
> I typed too fast *martin :)
>
> On Fri, Aug 18, 2017 at 8:04 PM, Martell Malone
> wrote:
>> Marin, please review :)
>>
>> commit 726ed8e9b9eea9a2c62c46108da9e014b85dca45
>> Author: Martell Malone
>> Date: Fri Aug 18 19:59:20 2017 +0100
>>
>> crt: Handle .ctors and .dtors within mingw-w64
>>
>> When building with clang we currently assume you will be
>> linking with llvm's lld or a bleeding edge binutils.
>> In future this will become the default method once
>> binutils support has settled and bumped a few versions.
>>
>> diff --git a/mingw-w64-crt/crt/crtdll.c b/mingw-w64-crt/crt/crtdll.c
>> index 07a18408..85035d49 100644
>> --- a/mingw-w64-crt/crt/crtdll.c
>> +++ b/mingw-w64-crt/crt/crtdll.c
>> @@ -40,6 +40,13 @@ extern _CRTALLOC(".CRT$XIZ") _PIFV __xi_z[];
>> extern _CRTALLOC(".CRT$XCA") _PVFV __xc_a[];
>> extern _CRTALLOC(".CRT$XCZ") _PVFV __xc_z[];
>>
>> +#ifdef __clang__
>> +__attribute__ (( __section__ (".ctors"), __used__ ,
>> aligned(sizeof(void * const void * __CTOR_LIST__ = (void *) -1;
>> +__attribute__ (( __section__ (".dtors"), __used__ ,
>> aligned(sizeof(void * const void * __DTOR_LIST__ = (void *) -1;
>> +__attribute__ (( __section__ (".ctors$zzz"), __used__ ,
>> aligned(sizeof(void * const void * __CTOR_END__ = (void *) 0;
>> +__attribute__ (( __section__ (".dtors$zzz"), __used__ ,
>> aligned(sizeof(void * const void * __DTOR_END__ = (void *) 0;
>> +#endif
>> +
>> /* TLS initialization hook. */
>> extern const PIMAGE_TLS_CALLBACK __dyn_tls_init_callback;
>>
>> diff --git a/mingw-w64-crt/crt/crtexe.c b/mingw-w64-crt/crt/crtexe.c
>> index ae37e0fe..e3a84784 100644
>> --- a/mingw-w64-crt/crt/crtexe.c
>> +++ b/mingw-w64-crt/crt/crtexe.c
>> @@ -60,6 +60,13 @@ extern _CRTALLOC(".CRT$XIZ") _PIFV __xi_z[];
>> extern _CRTALLOC(".CRT$XCA") _PVFV __xc_a[];
>> extern _CRTALLOC(".CRT$XCZ") _PVFV __xc_z[];
>>
>> +#ifdef __clang__
>> +__attribute__ (( __section__ (".ctors"), __used__ ,
>> aligned(sizeof(void * const void * __CTOR_LIST__ = (void *) -1;
>> +__attribute__ (( __section__ (".dtors"), __used__ ,
>> aligned(sizeof(void * const void * __DTOR_LIST__ = (void *) -1;
>> +__attribute__ (( __section__ (".ctors$zzz"), __used__ ,
>> aligned(sizeof(void * const void * __CTOR_END__ = (void *) 0;
>> +__attribute__ (( __section__ (".dtors$zzz"), __used__ ,
>> aligned(sizeof(void * const void * __DTOR_END__ = (void *) 0;
>> +#endif
>> +
>> /* TLS initialization hook. */
>> extern const PIMAGE_TLS_CALLBACK __dyn_tls_init_callback;
>>
>> diff --git a/mingw-w64-crt/crt/gccmain.c b/mingw-w64-crt/crt/gccmain.c
>> index fc0e3500..bf035d77 100644
>> --- a/mingw-w64-crt/crt/gccmain.c
>> +++ b/mingw-w64-crt/crt/gccmain.c
>> @@ -16,6 +16,31 @@ void __do_global_dtors (void);
>> void __do_global_ctors (void);
>> void __main (void);
>>
>> +#ifdef __clang__
>> +extern func_ptr __CTOR_END__[];
>> +extern func_ptr __DTOR_END__[];
>> +
>> +void __do_global_dtors (void)
>> +{
>> + static func_ptr *p = __DTOR_LIST__ + 1;
>> + while(p < __DTOR_END__) {
>> +if (*p) (*(p)) ();
>> + p++;
>> + }
>> +}
>> +
>> +void __do_global_ctors (void)
>> +{
>> + static func_ptr *p = __CTOR_END__ - 1;
>> + while(p > __CTOR_LIST__) {
>> +if (*p) (*(p)) ();
>> + p--;
>> + }
>> + atexit (__do_global_dtors);
>> +}
>> +
>> +#else
>> +
>> void
>> __do_global_dtors (void)
>> {
>> @@ -47,6 +72,8 @@ __do_global_ctors (void)
>>atexit (__do_global_dtors);
>> }
>>
>> +#endif
>> +
>> static int initialized = 0;
>>
>> void
>>
>> On Fri, Aug 18, 2017 at 7:52 PM, Martell Malone
>> wrote:
>>> In that case I will be back with a patch shortly for you to review.
>>> It might look ugly because of a large __clang__ ifdef block but should work.
>>>
>>> On Fri, Aug 18, 2017 at 7:50 PM, Martin Storsjö wrote:
On Fri, 18 Aug 2017, Martell Malone wrote:
> David, I also want to remove KEEP (*(.ctors)); which seems to cause a bug
> when linking in conjunction with KEEP (*(SORT_BY_NAME(.ctors.*))) and our
> new mingw-w64 markers. I have details in this email on binutils ml.
> https://sourceware.org/ml/binutils/2017-08/msg00078.html
> I have to create a minified test case for this to get approval to remove
> that line.
>
> Martin, I am fine with adding a __clang__ guard around the implementation
> if we want to land it now rather then keeping it out of tree?
> Kai any objections?
That'd be great yeah. Once we can build at least simple C apps without any
out-of-tree patches, it'll be a much lower barrier for entry for a lot of
more people.
IIRC Kai at least ok'd the patch once l
Re: [Mingw-w64-public] [PATCH] Handle __CTOR_LIST__ for clang
Martell, what was wrong with the sorting in the old binutils? It seems like the only thing you're doing is changing "SORT" to "SORT_BY_NAME" but I couldn't easily tell if that will make a difference. --David On Fri, Aug 18, 2017 at 11:11 AM, Martell Malone wrote: >> >> suddenly requiring the absolutely latest binutils, right? > > Correct we will need the next binutils release as a min version. > I don't think we need a condition we should just specify a new min binutils > version for mingw-w64 to require. > jon_y said this to me in the past, I think we should wait until all your > crt patch changes land in tree first though incase someone wanted to make a > v6 branch before this hits master. > > On Thu, Aug 17, 2017 at 9:00 PM, Martin Storsjö wrote: > >> On Mon, 14 Aug 2017, Martell Malone wrote: >> >> Can you briefly summarize what change this does and why it's necessary, > since the plain mingw patch as such seems to work already both with binutils ld and with lld? Is it in order to guarantee that the symbols in the mingw patch are sorted correctly so that we can be sure that the markers are set correctly? >>> >>> Sure, PROVIDE(__CTOR_LIST__ = .); is now used so that if we define >>> __CTOR_LIST__ in our code the linker doesn't create it. >>> We could probably do the same for __CTOR_END__ but I don't want to be too >>> intrusive, will see what Nick says here. >>> This is so that when linking with ld we do not get extra unneeded markers. >>> >>> It doesn't work currently with binutils ld because the sorting is >>> different >>> from what LD and LINK.exe does, we may have discovered a bug here actually >>> which I raised on the list. >>> >>> Does lld need a similar patch as well, or does it already do some similar sorting? And what about link.exe? >>> >>> No, both link.exe and lld work just fine as is because of the sorting. >>> >> >> So even if/when binutils get this fixed, I guess we can't just switch to >> this behaviour, suddenly requiring the absolutely latest binutils, right? >> So once this goes in, it needs to be behind some sort of "clang || binutils >> >= verynew" condition? >> >> >> // Martin >> >> >> -- >> Check out the vibrant tech community on one of the world's most >> engaging tech sites, Slashdot.org! http://sdm.link/slashdot >> ___ >> Mingw-w64-public mailing list >> Mingw-w64-public@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public >> > -- > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > ___ > Mingw-w64-public mailing list > Mingw-w64-public@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/mingw-w64-public -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [PATCH] Handle __CTOR_LIST__ for clang
I thought my last email explained it pretty well. The optimizer can do any kind of transformation it wants on the code as long as it doesn't change the behavior of well-defined programs. You seem to be stuck on the "__used__" attribute but that's not relevant to my argument. --David On Sun, Aug 6, 2017 at 8:08 AM, Martell Malone wrote: >> >> What I meant is that if GCC's optimizer ever figures out that we are >> comparing pointers that came from two different memory objects, it >> would know we are doing undefined behavior and would have a license to >> do whatever it wants, including removing that code. The way the loop >> is written right now is probably safer than anything that uses a >> symbol at the end of the constructors. > > I still do not see how this is relevant, we are specifying a used symbols > on specific section names. > The compiler has no recourse for optimising this out. > It is the linker that will organise the sections and fill in the branch > offsets. > Even with LTO this would not fail. > > On Sat, Aug 5, 2017 at 8:44 PM, David Grayson > wrote: > >> What I meant is that if GCC's optimizer ever figures out that we are >> comparing pointers that came from two different memory objects, it >> would know we are doing undefined behavior and would have a license to >> do whatever it wants, including removing that code. The way the loop >> is written right now is probably safer than anything that uses a >> symbol at the end of the constructors. >> >> --David >> >> On Sat, Aug 5, 2017 at 11:52 AM, Martell Malone >> wrote: >> >> >> >> I think Martell's last patch would have worked but it's not as safe as >> >> I would like it to be. I think the constructor and destructor lists >> > >> > should not be defined in gccmain.c where they are used, because then >> >> the compiler optimizer might start to get smart and stop optimizing >> >> things in a bad way. >> > >> > That won't happen, this is what the attribute __used__ is for. >> > The issue I have is about casting in a clean way. >> > I also don't see the point in iterating through a list to get to the end >> > and then navigating back through it again if you have a pointer to the >> last >> > element. >> > >> >> >> >> Also, I think we should add new symbols so there is no potential for a >> >> clash with the symbols defined by the linker script in binutils. >> > >> > As I said in a previous email this would be one way to solve it yes. >> > Here is what I said >> >> This would mean that programs linked with LD would have an extra 2 >> > pointers in the table but it should be fine otherwise. >> > I would be cleaner and better to change the linker script though. >> > >> > On Sat, Aug 5, 2017 at 6:15 PM, David Grayson >> > wrote: >> > >> >> Oops, here is the patch. >> >> >> >> On Sat, Aug 5, 2017 at 10:14 AM, David Grayson > > >> >> wrote: >> >> > I think Martell's last patch would have worked but it's not as safe as >> >> > I would like it to be. I think the constructor and destructor lists >> >> > should not be defined in gccmain.c where they are used, because then >> >> > the compiler optimizer might start to get smart and stop optimizing >> >> > things in a bad way. The kind of pointer arithmetic we're doing would >> >> > be undefined behavior since we're intentionally getting a pointer to >> >> > an object and then reading past the end of that object. >> >> > >> >> > Also, I think we should add new symbols so there is no potential for a >> >> > clash with the symbols defined by the linker script in binutils. >> >> > >> >> > So, attached to this email is a patch that worked for me (I was able >> >> > to compile and run a Qt Widgets application). I'm not entirely sure >> >> > it would be a good patch to use though, since I'm not sure how GCC >> >> > picks names for its global constructor and destructor sections, and >> >> > how it sorts those names, so I'm not sure that the symbols we are >> >> > defining would really be in the right place. >> >> > >> >> > --David Grayson >> >> > >> >> > On Sat, Aug 5, 2017 at 4:45 AM, Martell Malone < >> martellmal...@gmail.com>
Re: [Mingw-w64-public] [PATCH 01/19] math: Add errors in assembly sources if no implementation exists
I would agree with Martin; I think it's a very good practice for source files to have an error or not define a function instead of defining a function that can't possibly work and letting the build proceed with a broken function. Compiler and linker errors are much easier to figure out than segmentation faults. If you try to do it with autoconf, it's easy for the autoconf layer to get out of sync with the rest of the source code, or for someone to decide they want to use their own build system instead of the autoconf layer. And it won't help very much when porting to a new architecture like Martin said. --David On Sun, Aug 6, 2017 at 3:37 AM, Martin Storsjö wrote: > On Sun, 6 Aug 2017, JonY via Mingw-w64-public wrote: > >> On 08/05/2017 09:14 PM, Martin Storsjö wrote: >>> >>> This helps finding unimplemented functions; otherwise the symbol >>> will exist, but won't contain any implementation, so the function >>> will end up pointing at whatever other function the linker places >>> next. >> >> >> I would prefer these checks be in the autoconfigury layer where: >> >> ...blah blah test... >> AC_CASE([$math_platform], >> [arm32], [AC_DEFINE(USE_ARM32_MATH)], >> [arm64], [...] >> [AC_MSG_ERROR([Unsupported platform]) >> ... >> >> >> That way, we don't need to keep growing the if/else macros as more >> platforms are added. >> >> Consider also using AM_CONDITIONAL and other automake constructs if >> they're separate files to be compiled. > > > I'm not sure I think this is somthing that would help with the issue I'm > trying to address here - I think that kinda misses the point. > > We already have things similar to that; we have a custom list of files to > build into libmingwex.a for each of the 4 architectures, so if desired, we > could easily split these assembly files into one for each architecture as > well. > > Currently there's code for x86 (32 and 64 bit) and 32 bit arm in the same > file. The consistent next step would be to add 64 bit arm into the same (see > patch 09/19) - in most cases, it's just a few 2-5 instruction snippets so > it's much less overhead to add to the same file instead of creating > completely new ones. If you want to, we could also split them into separate > files for each architecture. > > Currently, these source files are under this heading in Makefile.am: > > # These mingwex sources are target independent: > src_libmingwex=\ > crt/dllentry.ccrt/dllmain.c \ > ... > math/ceil.S > > > > Having configure error out if you build for a new unsupported architecture, > would help a user trying to build for another new, unsupported architecture, > to know that it's pointless to proceed. > > However, if you're the one trying to implement support for that new > architecture, the first thing you'd need to do is to update configure.ac and > add the new architecture to the list of "supported" ones, in order to even > configure the build. And then what? > > > Then you need to provide all the necessary functions for the platform. In > order to do that, you'd most probably start off with the source files for > one of the existing architectures (in my case, I took the list of source > files for arm32), read each and every one of the files manually and see > which of them need customizations for the new arch. > > The "read each file manually" step is something I think most programmers > would avoid and just go ahead and try compiling things - that's what I did. > > I took the list of source files for arm32 and tried building for arm64, and > fixed issues until it all built without errors and mostly without warnings. > > Some files would have an explicit #error that's easy to spot, and fix. Some > files would implicitly try building e.g. x86 assembly, and fail. > > For some other case, you might have a function completely missing, which > you'd notice when you try to link an app that uses that function. > > But the deal with these assembly file, that is so devious, is that it > assembles without error, and it even defines the symbol, but without > actually producing any code. If I had gotten linker errors about missing > symbols, or assembler errors or preprocessor errors, it would have been > obvious to spot the issue. > > On the other hand, I see almost all other asm files also have the same > issue. The other ones (stdio/scanf*.S) I had already noticed, since the rest > of the associated code clearly errored out and pointed out all of those > functions to me. > > // Martin > > -- > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > ___ > Mingw-w64-public mailing list > Mingw-w64-public@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/mingw-w64-public -- Check out the v
Re: [Mingw-w64-public] [PATCH] Handle __CTOR_LIST__ for clang
What I meant is that if GCC's optimizer ever figures out that we are
comparing pointers that came from two different memory objects, it
would know we are doing undefined behavior and would have a license to
do whatever it wants, including removing that code. The way the loop
is written right now is probably safer than anything that uses a
symbol at the end of the constructors.
--David
On Sat, Aug 5, 2017 at 11:52 AM, Martell Malone wrote:
>>
>> I think Martell's last patch would have worked but it's not as safe as
>> I would like it to be. I think the constructor and destructor lists
>
> should not be defined in gccmain.c where they are used, because then
>> the compiler optimizer might start to get smart and stop optimizing
>> things in a bad way.
>
> That won't happen, this is what the attribute __used__ is for.
> The issue I have is about casting in a clean way.
> I also don't see the point in iterating through a list to get to the end
> and then navigating back through it again if you have a pointer to the last
> element.
>
>>
>> Also, I think we should add new symbols so there is no potential for a
>> clash with the symbols defined by the linker script in binutils.
>
> As I said in a previous email this would be one way to solve it yes.
> Here is what I said
>> This would mean that programs linked with LD would have an extra 2
> pointers in the table but it should be fine otherwise.
> I would be cleaner and better to change the linker script though.
>
> On Sat, Aug 5, 2017 at 6:15 PM, David Grayson
> wrote:
>
>> Oops, here is the patch.
>>
>> On Sat, Aug 5, 2017 at 10:14 AM, David Grayson
>> wrote:
>> > I think Martell's last patch would have worked but it's not as safe as
>> > I would like it to be. I think the constructor and destructor lists
>> > should not be defined in gccmain.c where they are used, because then
>> > the compiler optimizer might start to get smart and stop optimizing
>> > things in a bad way. The kind of pointer arithmetic we're doing would
>> > be undefined behavior since we're intentionally getting a pointer to
>> > an object and then reading past the end of that object.
>> >
>> > Also, I think we should add new symbols so there is no potential for a
>> > clash with the symbols defined by the linker script in binutils.
>> >
>> > So, attached to this email is a patch that worked for me (I was able
>> > to compile and run a Qt Widgets application). I'm not entirely sure
>> > it would be a good patch to use though, since I'm not sure how GCC
>> > picks names for its global constructor and destructor sections, and
>> > how it sorts those names, so I'm not sure that the symbols we are
>> > defining would really be in the right place.
>> >
>> > --David Grayson
>> >
>> > On Sat, Aug 5, 2017 at 4:45 AM, Martell Malone
>> wrote:
>> >> Hey David,
>> >>
>> >>
>> >>> Your binutils patch did not apply cleanly to binutils-2.27 but I got
>> >>> it to work. It looks pretty dangerous to me because you removed the
>> >>> lines for keeping the .dtors, .dtor, .ctors, and .ctor sections. And
>> >>> you're using .ctors and .dtors in your other patch, and other code
>> >>> might use them too I suppose.
>> >>
>> >>
>> >> It applies cleanly to HEAD.
>> >> I changed to so that all it does is SORT the ctors and dtors sections.
>> >> Someone would have to confirm though.
>> >>
>> >> Maybe crtexe.c is not linked into shared libraries since they are not
>> EXEs.
>> >>
>> >> That is exactly what happened there crtdll.c is used instead.
>> >> Here is an updated patch which also applies to crtdll.c
>> >>
>> >> Also the only reason I am not putting it into gccmain.c is because I am
>> >> having problems with creating it and then using is as a array.
>> >> If someone is able to do that it would be much better.
>> >>
>> >> Transforming
>> >> __attribute__ (( __section__ (".ctors"), __used__ , aligned(sizeof(void
>> >> * const func_ptr __CTOR_LIST__[] = {(void *) -1};
>> >> into
>> >> func_ptr __CTOR_LIST__[]
>> >> is being problematic within the one source.
>> >>
>> >> I'd gladly take direction from someone here on that if they have any
>> ideas.
>> >>
>> >> Best,
>> >>
Re: [Mingw-w64-public] [PATCH] Handle __CTOR_LIST__ for clang
Oops, here is the patch.
On Sat, Aug 5, 2017 at 10:14 AM, David Grayson wrote:
> I think Martell's last patch would have worked but it's not as safe as
> I would like it to be. I think the constructor and destructor lists
> should not be defined in gccmain.c where they are used, because then
> the compiler optimizer might start to get smart and stop optimizing
> things in a bad way. The kind of pointer arithmetic we're doing would
> be undefined behavior since we're intentionally getting a pointer to
> an object and then reading past the end of that object.
>
> Also, I think we should add new symbols so there is no potential for a
> clash with the symbols defined by the linker script in binutils.
>
> So, attached to this email is a patch that worked for me (I was able
> to compile and run a Qt Widgets application). I'm not entirely sure
> it would be a good patch to use though, since I'm not sure how GCC
> picks names for its global constructor and destructor sections, and
> how it sorts those names, so I'm not sure that the symbols we are
> defining would really be in the right place.
>
> --David Grayson
>
> On Sat, Aug 5, 2017 at 4:45 AM, Martell Malone
> wrote:
>> Hey David,
>>
>>
>>> Your binutils patch did not apply cleanly to binutils-2.27 but I got
>>> it to work. It looks pretty dangerous to me because you removed the
>>> lines for keeping the .dtors, .dtor, .ctors, and .ctor sections. And
>>> you're using .ctors and .dtors in your other patch, and other code
>>> might use them too I suppose.
>>
>>
>> It applies cleanly to HEAD.
>> I changed to so that all it does is SORT the ctors and dtors sections.
>> Someone would have to confirm though.
>>
>> Maybe crtexe.c is not linked into shared libraries since they are not EXEs.
>>
>> That is exactly what happened there crtdll.c is used instead.
>> Here is an updated patch which also applies to crtdll.c
>>
>> Also the only reason I am not putting it into gccmain.c is because I am
>> having problems with creating it and then using is as a array.
>> If someone is able to do that it would be much better.
>>
>> Transforming
>> __attribute__ (( __section__ (".ctors"), __used__ , aligned(sizeof(void
>> * const func_ptr __CTOR_LIST__[] = {(void *) -1};
>> into
>> func_ptr __CTOR_LIST__[]
>> is being problematic within the one source.
>>
>> I'd gladly take direction from someone here on that if they have any ideas.
>>
>> Best,
>> Martell
>>
>> On Sat, Aug 5, 2017 at 5:53 AM, David Grayson
>> wrote:
>>
>>> With your latest two patches, the toolchain compiles but I get an
>>> error when building a shared library:
>>>
>>> /nix/store/k481dhv5hivggnjyb9rs95fz1k6ylhjz-mingw-w64-2017-08-03-i686-
>>> w64-mingw32/lib/../lib/libmingw32.a(lib32_libmingw32_a-gccmain.o):
>>> In function `_do_global_dtors':
>>> /tmp/nix-build-mingw-w64-2017-08-03-i686-w64-mingw32.drv-0/
>>> build_crt_and_headers/mingw-w64-crt/../../mingw-w64/mingw-
>>> w64-crt/crt/gccmain.c:25:
>>> undefined reference to `__DTOR_END__'
>>> /tmp/nix-build-mingw-w64-2017-08-03-i686-w64-mingw32.drv-0/
>>> build_crt_and_headers/mingw-w64-crt/../../mingw-w64/mingw-
>>> w64-crt/crt/gccmain.c:25:
>>> undefined reference to `__DTOR_END__'
>>> /nix/store/k481dhv5hivggnjyb9rs95fz1k6ylhjz-mingw-w64-2017-08-03-i686-
>>> w64-mingw32/lib/../lib/libmingw32.a(lib32_libmingw32_
>>> a-gccmain.o):gccmain.c:(.data+0x0):
>>> undefined reference to `__CTOR_END__'
>>>
>>> Maybe crtexe.c is not linked into shared libraries since they are not EXEs.
>>>
>>> --David
>>>
>>> On Fri, Aug 4, 2017 at 6:12 PM, David Grayson
>>> wrote:
>>> > Oh, I mean that I got the patch to apply, but I don't know if it
>>> > really *works*; the toolchain is still building at this time. --David
>>> >
>>> > On Fri, Aug 4, 2017 at 6:11 PM, David Grayson
>>> wrote:
>>> >> Your binutils patch did not apply cleanly to binutils-2.27 but I got
>>> >> it to work. It looks pretty dangerous to me because you removed the
>>> >> lines for keeping the .dtors, .dtor, .ctors, and .ctor sections. And
>>> >> you're using .ctors and .dtors in your other patch, and other code
>>> >> might use them too I suppose.
>>> >>
>>> >> --David
>>> >>
>>> >> On Fri,
Re: [Mingw-w64-public] [PATCH] Handle __CTOR_LIST__ for clang
I think Martell's last patch would have worked but it's not as safe as
I would like it to be. I think the constructor and destructor lists
should not be defined in gccmain.c where they are used, because then
the compiler optimizer might start to get smart and stop optimizing
things in a bad way. The kind of pointer arithmetic we're doing would
be undefined behavior since we're intentionally getting a pointer to
an object and then reading past the end of that object.
Also, I think we should add new symbols so there is no potential for a
clash with the symbols defined by the linker script in binutils.
So, attached to this email is a patch that worked for me (I was able
to compile and run a Qt Widgets application). I'm not entirely sure
it would be a good patch to use though, since I'm not sure how GCC
picks names for its global constructor and destructor sections, and
how it sorts those names, so I'm not sure that the symbols we are
defining would really be in the right place.
--David Grayson
On Sat, Aug 5, 2017 at 4:45 AM, Martell Malone wrote:
> Hey David,
>
>
>> Your binutils patch did not apply cleanly to binutils-2.27 but I got
>> it to work. It looks pretty dangerous to me because you removed the
>> lines for keeping the .dtors, .dtor, .ctors, and .ctor sections. And
>> you're using .ctors and .dtors in your other patch, and other code
>> might use them too I suppose.
>
>
> It applies cleanly to HEAD.
> I changed to so that all it does is SORT the ctors and dtors sections.
> Someone would have to confirm though.
>
> Maybe crtexe.c is not linked into shared libraries since they are not EXEs.
>
> That is exactly what happened there crtdll.c is used instead.
> Here is an updated patch which also applies to crtdll.c
>
> Also the only reason I am not putting it into gccmain.c is because I am
> having problems with creating it and then using is as a array.
> If someone is able to do that it would be much better.
>
> Transforming
> __attribute__ (( __section__ (".ctors"), __used__ , aligned(sizeof(void
> * const func_ptr __CTOR_LIST__[] = {(void *) -1};
> into
> func_ptr __CTOR_LIST__[]
> is being problematic within the one source.
>
> I'd gladly take direction from someone here on that if they have any ideas.
>
> Best,
> Martell
>
> On Sat, Aug 5, 2017 at 5:53 AM, David Grayson
> wrote:
>
>> With your latest two patches, the toolchain compiles but I get an
>> error when building a shared library:
>>
>> /nix/store/k481dhv5hivggnjyb9rs95fz1k6ylhjz-mingw-w64-2017-08-03-i686-
>> w64-mingw32/lib/../lib/libmingw32.a(lib32_libmingw32_a-gccmain.o):
>> In function `_do_global_dtors':
>> /tmp/nix-build-mingw-w64-2017-08-03-i686-w64-mingw32.drv-0/
>> build_crt_and_headers/mingw-w64-crt/../../mingw-w64/mingw-
>> w64-crt/crt/gccmain.c:25:
>> undefined reference to `__DTOR_END__'
>> /tmp/nix-build-mingw-w64-2017-08-03-i686-w64-mingw32.drv-0/
>> build_crt_and_headers/mingw-w64-crt/../../mingw-w64/mingw-
>> w64-crt/crt/gccmain.c:25:
>> undefined reference to `__DTOR_END__'
>> /nix/store/k481dhv5hivggnjyb9rs95fz1k6ylhjz-mingw-w64-2017-08-03-i686-
>> w64-mingw32/lib/../lib/libmingw32.a(lib32_libmingw32_
>> a-gccmain.o):gccmain.c:(.data+0x0):
>> undefined reference to `__CTOR_END__'
>>
>> Maybe crtexe.c is not linked into shared libraries since they are not EXEs.
>>
>> --David
>>
>> On Fri, Aug 4, 2017 at 6:12 PM, David Grayson
>> wrote:
>> > Oh, I mean that I got the patch to apply, but I don't know if it
>> > really *works*; the toolchain is still building at this time. --David
>> >
>> > On Fri, Aug 4, 2017 at 6:11 PM, David Grayson
>> wrote:
>> >> Your binutils patch did not apply cleanly to binutils-2.27 but I got
>> >> it to work. It looks pretty dangerous to me because you removed the
>> >> lines for keeping the .dtors, .dtor, .ctors, and .ctor sections. And
>> >> you're using .ctors and .dtors in your other patch, and other code
>> >> might use them too I suppose.
>> >>
>> >> --David
>> >>
>> >> On Fri, Aug 4, 2017 at 5:39 PM, Martell Malone
>> wrote:
>> >>> Hey David,
>> >>>
>> >>> This could be caused by gcc including it's own crtbegin.o and crtend.o
>> >>> I managed to install a toolchain with brew and I swapped out gcc's and
>> >>> mingw-w64's crtbegin and crtend.
>> >>> Everything seems to work here as intended.
>> >>> Attached is an updated patch that avoids crt
Re: [Mingw-w64-public] [PATCH] Handle __CTOR_LIST__ for clang
With your latest two patches, the toolchain compiles but I get an error when building a shared library: /nix/store/k481dhv5hivggnjyb9rs95fz1k6ylhjz-mingw-w64-2017-08-03-i686-w64-mingw32/lib/../lib/libmingw32.a(lib32_libmingw32_a-gccmain.o): In function `_do_global_dtors': /tmp/nix-build-mingw-w64-2017-08-03-i686-w64-mingw32.drv-0/build_crt_and_headers/mingw-w64-crt/../../mingw-w64/mingw-w64-crt/crt/gccmain.c:25: undefined reference to `__DTOR_END__' /tmp/nix-build-mingw-w64-2017-08-03-i686-w64-mingw32.drv-0/build_crt_and_headers/mingw-w64-crt/../../mingw-w64/mingw-w64-crt/crt/gccmain.c:25: undefined reference to `__DTOR_END__' /nix/store/k481dhv5hivggnjyb9rs95fz1k6ylhjz-mingw-w64-2017-08-03-i686-w64-mingw32/lib/../lib/libmingw32.a(lib32_libmingw32_a-gccmain.o):gccmain.c:(.data+0x0): undefined reference to `__CTOR_END__' Maybe crtexe.c is not linked into shared libraries since they are not EXEs. --David On Fri, Aug 4, 2017 at 6:12 PM, David Grayson wrote: > Oh, I mean that I got the patch to apply, but I don't know if it > really *works*; the toolchain is still building at this time. --David > > On Fri, Aug 4, 2017 at 6:11 PM, David Grayson wrote: >> Your binutils patch did not apply cleanly to binutils-2.27 but I got >> it to work. It looks pretty dangerous to me because you removed the >> lines for keeping the .dtors, .dtor, .ctors, and .ctor sections. And >> you're using .ctors and .dtors in your other patch, and other code >> might use them too I suppose. >> >> --David >> >> On Fri, Aug 4, 2017 at 5:39 PM, Martell Malone >> wrote: >>> Hey David, >>> >>> This could be caused by gcc including it's own crtbegin.o and crtend.o >>> I managed to install a toolchain with brew and I swapped out gcc's and >>> mingw-w64's crtbegin and crtend. >>> Everything seems to work here as intended. >>> Attached is an updated patch that avoids crtbegin and crtend that should >>> work along with a patch for binutils. >>> >>> Kai could you give some input on the binutils patch. >>> On a side note while we are at this we should change __image_base__ >>> to ___ImageBase and __ImageBase on x86 and x64 respectively. >>> Best, >>> Martell >>> >>> On Sat, Aug 5, 2017 at 12:20 AM, David Grayson >>> wrote: >>> >>>> Martell: >>>> >>>> My setup ( https://github.com/DavidEGrayson/nixcrpkgs ) makes it quite >>>> easy to try random patches and make sure that GCC can still be >>>> bootstrapped and that I can build non-trivial applications. I tried >>>> your patch (after fixing the linebreaks added by GMail) but >>>> unfortunately it doesn't work. >>>> >>>> When building the final GCC, I got this error: >>>> >>>> >>>> checking for ld that supports -Wl,--gc-sections... configure: error: >>>> Link tests are not allowed after GCC_NO_EXECUTABLES. >>>> make[1]: *** [Makefile:9917: configure-target-libstdc++-v3] Error 1 >>>> make[1]: Leaving directory >>>> '/tmp/nix-build-gcc-6.3.0-i686-w64-mingw32.drv-0/build' >>>> make: *** [Makefile:878: all] Error 2 >>>> >>>> >>>> I've experienced this before and it just means something went wrong >>>> earlier in the configure script, and GCC, in its infinite wisdom, >>>> decided that it was targeting a system that does not support >>>> executables (?). Digging through the config.log for libstdc++-v3, I >>>> found a suspicious error: >>>> >>>> >>>> configure:3952: $? = 1 >>>> configure:3968: >>>> /tmp/nix-build-gcc-6.3.0-i686-w64-mingw32.drv-0/build/./gcc/xgcc >>>> -B/tmp/nix-build-gcc-6.3.0-i686-w64-m >>>> ingw32.drv-0/build/./gcc/ >>>> -L/nix/store/s27xhxkbq4qxadhzpn5vh5kkffnfvizy-gcc-6.3.0- >>>> i686-w64-mingw32/i686-w64-mingw32/li >>>> b -L/nix/store/s27xhxkbq4qxadhzpn5vh5kkffnfvizy-gcc-6.3.0- >>>> i686-w64-mingw32/mingw/lib >>>> -isystem /nix/store/s27xhxkbq4qxa >>>> dhzpn5vh5kkffnfvizy-gcc-6.3.0-i686-w64-mingw32/i686-w64-mingw32/include >>>> -isystem /nix/store/s27xhxkbq4qxadhzpn5vh5kkff >>>> nfvizy-gcc-6.3.0-i686-w64-mingw32/mingw/include >>>> -B/nix/store/s27xhxkbq4qxadhzpn5vh5kkffnfvizy-gcc-6.3.0-i686-w64-mingw >>>> 32/i686-w64-mingw32/bin/ >>>> -B/nix/store/s27xhxkbq4qxadhzpn5vh5kkffnfvizy-gcc-6.3.0- >>>> i686-w64-mingw32/i686-w64-mingw32/lib >>>> / -isyste
Re: [Mingw-w64-public] [PATCH] Handle __CTOR_LIST__ for clang
Oh, I mean that I got the patch to apply, but I don't know if it really *works*; the toolchain is still building at this time. --David On Fri, Aug 4, 2017 at 6:11 PM, David Grayson wrote: > Your binutils patch did not apply cleanly to binutils-2.27 but I got > it to work. It looks pretty dangerous to me because you removed the > lines for keeping the .dtors, .dtor, .ctors, and .ctor sections. And > you're using .ctors and .dtors in your other patch, and other code > might use them too I suppose. > > --David > > On Fri, Aug 4, 2017 at 5:39 PM, Martell Malone > wrote: >> Hey David, >> >> This could be caused by gcc including it's own crtbegin.o and crtend.o >> I managed to install a toolchain with brew and I swapped out gcc's and >> mingw-w64's crtbegin and crtend. >> Everything seems to work here as intended. >> Attached is an updated patch that avoids crtbegin and crtend that should >> work along with a patch for binutils. >> >> Kai could you give some input on the binutils patch. >> On a side note while we are at this we should change __image_base__ >> to ___ImageBase and __ImageBase on x86 and x64 respectively. >> Best, >> Martell >> >> On Sat, Aug 5, 2017 at 12:20 AM, David Grayson >> wrote: >> >>> Martell: >>> >>> My setup ( https://github.com/DavidEGrayson/nixcrpkgs ) makes it quite >>> easy to try random patches and make sure that GCC can still be >>> bootstrapped and that I can build non-trivial applications. I tried >>> your patch (after fixing the linebreaks added by GMail) but >>> unfortunately it doesn't work. >>> >>> When building the final GCC, I got this error: >>> >>> >>> checking for ld that supports -Wl,--gc-sections... configure: error: >>> Link tests are not allowed after GCC_NO_EXECUTABLES. >>> make[1]: *** [Makefile:9917: configure-target-libstdc++-v3] Error 1 >>> make[1]: Leaving directory >>> '/tmp/nix-build-gcc-6.3.0-i686-w64-mingw32.drv-0/build' >>> make: *** [Makefile:878: all] Error 2 >>> >>> >>> I've experienced this before and it just means something went wrong >>> earlier in the configure script, and GCC, in its infinite wisdom, >>> decided that it was targeting a system that does not support >>> executables (?). Digging through the config.log for libstdc++-v3, I >>> found a suspicious error: >>> >>> >>> configure:3952: $? = 1 >>> configure:3968: >>> /tmp/nix-build-gcc-6.3.0-i686-w64-mingw32.drv-0/build/./gcc/xgcc >>> -B/tmp/nix-build-gcc-6.3.0-i686-w64-m >>> ingw32.drv-0/build/./gcc/ >>> -L/nix/store/s27xhxkbq4qxadhzpn5vh5kkffnfvizy-gcc-6.3.0- >>> i686-w64-mingw32/i686-w64-mingw32/li >>> b -L/nix/store/s27xhxkbq4qxadhzpn5vh5kkffnfvizy-gcc-6.3.0- >>> i686-w64-mingw32/mingw/lib >>> -isystem /nix/store/s27xhxkbq4qxa >>> dhzpn5vh5kkffnfvizy-gcc-6.3.0-i686-w64-mingw32/i686-w64-mingw32/include >>> -isystem /nix/store/s27xhxkbq4qxadhzpn5vh5kkff >>> nfvizy-gcc-6.3.0-i686-w64-mingw32/mingw/include >>> -B/nix/store/s27xhxkbq4qxadhzpn5vh5kkffnfvizy-gcc-6.3.0-i686-w64-mingw >>> 32/i686-w64-mingw32/bin/ >>> -B/nix/store/s27xhxkbq4qxadhzpn5vh5kkffnfvizy-gcc-6.3.0- >>> i686-w64-mingw32/i686-w64-mingw32/lib >>> / -isystem /nix/store/s27xhxkbq4qxadhzpn5vh5kkffnfvizy-gcc-6.3.0-i686- >>> w64-mingw32/i686-w64-mingw32/include >>> -isystem /n >>> ix/store/s27xhxkbq4qxadhzpn5vh5kkffnfvizy-gcc-6.3.0-i686- >>> w64-mingw32/i686-w64-mingw32/sys-include >>>-o conftest -g -O >>> 2 conftest.c >&5 >>> /nix/store/262jyalfa9jz5say3782fcdh2zw4n301-mingw-w64-2017- >>> 08-03-i686-w64-mingw32/lib/../lib/libmingw32.a(lib32_libmin >>> gw32_a-gccmain.o): In function `_do_global_dtors': >>> /tmp/nix-build-mingw-w64-2017-08-03-i686-w64-mingw32.drv-0/b >>> uild_crt_and_headers/mingw-w64-crt/../../mingw-w64/mingw-w >>> 64-crt/crt/gccmain.c:25: undefined reference to `__MINGW_DTOR_LIST__' >>> /tmp/nix-build-mingw-w64-2017-08-03-i686-w64-mingw32.drv-0/b >>> uild_crt_and_headers/mingw-w64-crt/../../mingw-w64/mingw-w >>> 64-crt/crt/gccmain.c:25: undefined reference to `__MINGW_DTOR_END__' >>> /tmp/nix-build-mingw-w64-2017-08-03-i686-w64-mingw32.drv-0/b >>> uild_crt_and_headers/mingw-w64-crt/../../mingw-w64/mingw-w >>> 64-crt/crt/gccmain.c:25: undefined reference to `__MINGW_DTOR_END__' >>> /nix/store/262jyalfa9jz5say3782fcdh2
Re: [Mingw-w64-public] [PATCH] Handle __CTOR_LIST__ for clang
Your binutils patch did not apply cleanly to binutils-2.27 but I got it to work. It looks pretty dangerous to me because you removed the lines for keeping the .dtors, .dtor, .ctors, and .ctor sections. And you're using .ctors and .dtors in your other patch, and other code might use them too I suppose. --David On Fri, Aug 4, 2017 at 5:39 PM, Martell Malone wrote: > Hey David, > > This could be caused by gcc including it's own crtbegin.o and crtend.o > I managed to install a toolchain with brew and I swapped out gcc's and > mingw-w64's crtbegin and crtend. > Everything seems to work here as intended. > Attached is an updated patch that avoids crtbegin and crtend that should > work along with a patch for binutils. > > Kai could you give some input on the binutils patch. > On a side note while we are at this we should change __image_base__ > to ___ImageBase and __ImageBase on x86 and x64 respectively. > Best, > Martell > > On Sat, Aug 5, 2017 at 12:20 AM, David Grayson > wrote: > >> Martell: >> >> My setup ( https://github.com/DavidEGrayson/nixcrpkgs ) makes it quite >> easy to try random patches and make sure that GCC can still be >> bootstrapped and that I can build non-trivial applications. I tried >> your patch (after fixing the linebreaks added by GMail) but >> unfortunately it doesn't work. >> >> When building the final GCC, I got this error: >> >> >> checking for ld that supports -Wl,--gc-sections... configure: error: >> Link tests are not allowed after GCC_NO_EXECUTABLES. >> make[1]: *** [Makefile:9917: configure-target-libstdc++-v3] Error 1 >> make[1]: Leaving directory >> '/tmp/nix-build-gcc-6.3.0-i686-w64-mingw32.drv-0/build' >> make: *** [Makefile:878: all] Error 2 >> >> >> I've experienced this before and it just means something went wrong >> earlier in the configure script, and GCC, in its infinite wisdom, >> decided that it was targeting a system that does not support >> executables (?). Digging through the config.log for libstdc++-v3, I >> found a suspicious error: >> >> >> configure:3952: $? = 1 >> configure:3968: >> /tmp/nix-build-gcc-6.3.0-i686-w64-mingw32.drv-0/build/./gcc/xgcc >> -B/tmp/nix-build-gcc-6.3.0-i686-w64-m >> ingw32.drv-0/build/./gcc/ >> -L/nix/store/s27xhxkbq4qxadhzpn5vh5kkffnfvizy-gcc-6.3.0- >> i686-w64-mingw32/i686-w64-mingw32/li >> b -L/nix/store/s27xhxkbq4qxadhzpn5vh5kkffnfvizy-gcc-6.3.0- >> i686-w64-mingw32/mingw/lib >> -isystem /nix/store/s27xhxkbq4qxa >> dhzpn5vh5kkffnfvizy-gcc-6.3.0-i686-w64-mingw32/i686-w64-mingw32/include >> -isystem /nix/store/s27xhxkbq4qxadhzpn5vh5kkff >> nfvizy-gcc-6.3.0-i686-w64-mingw32/mingw/include >> -B/nix/store/s27xhxkbq4qxadhzpn5vh5kkffnfvizy-gcc-6.3.0-i686-w64-mingw >> 32/i686-w64-mingw32/bin/ >> -B/nix/store/s27xhxkbq4qxadhzpn5vh5kkffnfvizy-gcc-6.3.0- >> i686-w64-mingw32/i686-w64-mingw32/lib >> / -isystem /nix/store/s27xhxkbq4qxadhzpn5vh5kkffnfvizy-gcc-6.3.0-i686- >> w64-mingw32/i686-w64-mingw32/include >> -isystem /n >> ix/store/s27xhxkbq4qxadhzpn5vh5kkffnfvizy-gcc-6.3.0-i686- >> w64-mingw32/i686-w64-mingw32/sys-include >>-o conftest -g -O >> 2 conftest.c >&5 >> /nix/store/262jyalfa9jz5say3782fcdh2zw4n301-mingw-w64-2017- >> 08-03-i686-w64-mingw32/lib/../lib/libmingw32.a(lib32_libmin >> gw32_a-gccmain.o): In function `_do_global_dtors': >> /tmp/nix-build-mingw-w64-2017-08-03-i686-w64-mingw32.drv-0/b >> uild_crt_and_headers/mingw-w64-crt/../../mingw-w64/mingw-w >> 64-crt/crt/gccmain.c:25: undefined reference to `__MINGW_DTOR_LIST__' >> /tmp/nix-build-mingw-w64-2017-08-03-i686-w64-mingw32.drv-0/b >> uild_crt_and_headers/mingw-w64-crt/../../mingw-w64/mingw-w >> 64-crt/crt/gccmain.c:25: undefined reference to `__MINGW_DTOR_END__' >> /tmp/nix-build-mingw-w64-2017-08-03-i686-w64-mingw32.drv-0/b >> uild_crt_and_headers/mingw-w64-crt/../../mingw-w64/mingw-w >> 64-crt/crt/gccmain.c:25: undefined reference to `__MINGW_DTOR_END__' >> /nix/store/262jyalfa9jz5say3782fcdh2zw4n301-mingw-w64-2017- >> 08-03-i686-w64-mingw32/lib/../lib/libmingw32.a(lib32_libmin >> gw32_a-gccmain.o): In function `_do_global_ctors': >> /tmp/nix-build-mingw-w64-2017-08-03-i686-w64-mingw32.drv-0/b >> uild_crt_and_headers/mingw-w64-crt/../../mingw-w64/mingw-w >> 64-crt/crt/gccmain.c:35: undefined reference to `__MINGW_CTOR_END__' >> /tmp/nix-build-mingw-w64-2017-08-03-i686-w64-mingw32.drv-0/b >> uild_crt_and_headers/mingw-w64-crt/../../mingw-w64/mingw-w >> 64-crt/crt/gccmain.c:35: undefined referenc
Re: [Mingw-w64-public] [PATCH] Handle __CTOR_LIST__ for clang
Martell:
My setup ( https://github.com/DavidEGrayson/nixcrpkgs ) makes it quite
easy to try random patches and make sure that GCC can still be
bootstrapped and that I can build non-trivial applications. I tried
your patch (after fixing the linebreaks added by GMail) but
unfortunately it doesn't work.
When building the final GCC, I got this error:
checking for ld that supports -Wl,--gc-sections... configure: error:
Link tests are not allowed after GCC_NO_EXECUTABLES.
make[1]: *** [Makefile:9917: configure-target-libstdc++-v3] Error 1
make[1]: Leaving directory
'/tmp/nix-build-gcc-6.3.0-i686-w64-mingw32.drv-0/build'
make: *** [Makefile:878: all] Error 2
I've experienced this before and it just means something went wrong
earlier in the configure script, and GCC, in its infinite wisdom,
decided that it was targeting a system that does not support
executables (?). Digging through the config.log for libstdc++-v3, I
found a suspicious error:
configure:3952: $? = 1
configure:3968:
/tmp/nix-build-gcc-6.3.0-i686-w64-mingw32.drv-0/build/./gcc/xgcc
-B/tmp/nix-build-gcc-6.3.0-i686-w64-m
ingw32.drv-0/build/./gcc/
-L/nix/store/s27xhxkbq4qxadhzpn5vh5kkffnfvizy-gcc-6.3.0-i686-w64-mingw32/i686-w64-mingw32/li
b
-L/nix/store/s27xhxkbq4qxadhzpn5vh5kkffnfvizy-gcc-6.3.0-i686-w64-mingw32/mingw/lib
-isystem /nix/store/s27xhxkbq4qxa
dhzpn5vh5kkffnfvizy-gcc-6.3.0-i686-w64-mingw32/i686-w64-mingw32/include
-isystem /nix/store/s27xhxkbq4qxadhzpn5vh5kkff
nfvizy-gcc-6.3.0-i686-w64-mingw32/mingw/include
-B/nix/store/s27xhxkbq4qxadhzpn5vh5kkffnfvizy-gcc-6.3.0-i686-w64-mingw
32/i686-w64-mingw32/bin/
-B/nix/store/s27xhxkbq4qxadhzpn5vh5kkffnfvizy-gcc-6.3.0-i686-w64-mingw32/i686-w64-mingw32/lib
/ -isystem
/nix/store/s27xhxkbq4qxadhzpn5vh5kkffnfvizy-gcc-6.3.0-i686-w64-mingw32/i686-w64-mingw32/include
-isystem /n
ix/store/s27xhxkbq4qxadhzpn5vh5kkffnfvizy-gcc-6.3.0-i686-w64-mingw32/i686-w64-mingw32/sys-include
-o conftest -g -O
2 conftest.c >&5
/nix/store/262jyalfa9jz5say3782fcdh2zw4n301-mingw-w64-2017-08-03-i686-w64-mingw32/lib/../lib/libmingw32.a(lib32_libmin
gw32_a-gccmain.o): In function `_do_global_dtors':
/tmp/nix-build-mingw-w64-2017-08-03-i686-w64-mingw32.drv-0/build_crt_and_headers/mingw-w64-crt/../../mingw-w64/mingw-w
64-crt/crt/gccmain.c:25: undefined reference to `__MINGW_DTOR_LIST__'
/tmp/nix-build-mingw-w64-2017-08-03-i686-w64-mingw32.drv-0/build_crt_and_headers/mingw-w64-crt/../../mingw-w64/mingw-w
64-crt/crt/gccmain.c:25: undefined reference to `__MINGW_DTOR_END__'
/tmp/nix-build-mingw-w64-2017-08-03-i686-w64-mingw32.drv-0/build_crt_and_headers/mingw-w64-crt/../../mingw-w64/mingw-w
64-crt/crt/gccmain.c:25: undefined reference to `__MINGW_DTOR_END__'
/nix/store/262jyalfa9jz5say3782fcdh2zw4n301-mingw-w64-2017-08-03-i686-w64-mingw32/lib/../lib/libmingw32.a(lib32_libmin
gw32_a-gccmain.o): In function `_do_global_ctors':
/tmp/nix-build-mingw-w64-2017-08-03-i686-w64-mingw32.drv-0/build_crt_and_headers/mingw-w64-crt/../../mingw-w64/mingw-w
64-crt/crt/gccmain.c:35: undefined reference to `__MINGW_CTOR_END__'
/tmp/nix-build-mingw-w64-2017-08-03-i686-w64-mingw32.drv-0/build_crt_and_headers/mingw-w64-crt/../../mingw-w64/mingw-w
64-crt/crt/gccmain.c:35: undefined reference to `__MINGW_CTOR_LIST__'
/tmp/nix-build-mingw-w64-2017-08-03-i686-w64-mingw32.drv-0/build_crt_and_headers/mingw-w64-crt/../../mingw-w64/mingw-w
64-crt/crt/gccmain.c:35: undefined reference to `__MINGW_CTOR_LIST__'
I'm not sure why those things would be undefined, but the order of
linking of these libraries does matter and perhaps they are being
linked in the wrong order.
--David
On Fri, Aug 4, 2017 at 12:50 PM, Martell Malone wrote:
> Okay lets just solve this.
> I believe the following should work for both clang and gcc
> I added a test case at the bottom also.
>
> diff --git a/mingw-w64-crt/crt/crtbegin.c b/mingw-w64-crt/crt/crtbegin.c
> index 39c0d856..1672f7b9 100644
> --- a/mingw-w64-crt/crt/crtbegin.c
> +++ b/mingw-w64-crt/crt/crtbegin.c
> @@ -4,3 +4,5 @@
> * No warranty is given; refer to the file DISCLAIMER.PD within this
> package.
> */
>
> +__attribute__ (( __section__ (".ctors"), __used__ , aligned(sizeof(void
> * const void * __MINGW_CTOR_LIST__ = (void *) -1;
> +__attribute__ (( __section__ (".dtors"), __used__ , aligned(sizeof(void
> * const void * __MINGW_DTOR_LIST__ = (void *) -1;
> diff --git a/mingw-w64-crt/crt/crtend.c b/mingw-w64-crt/crt/crtend.c
> index 39c0d856..d1b6b426 100644
> --- a/mingw-w64-crt/crt/crtend.c
> +++ b/mingw-w64-crt/crt/crtend.c
> @@ -4,3 +4,5 @@
> * No warranty is given; refer to the file DISCLAIMER.PD within this
> package.
> */
>
> +__attribute__ (( __section__ (".ctors$zzz"), __used__ ,
> aligned(sizeof(void * const void * __MINGW_CTOR_END__ = (void *) 0;
> +__attribute__ (( __section__ (".dtors$zzz"), __used__ ,
> aligned(sizeof(void * const void * __MINGW_DTOR_END__ = (void *) 0;
> diff --git a/mingw-w64-crt/crt/gccmain.c b/mingw-w64-crt/crt/gccmain.c
> index fc0e350
Re: [Mingw-w64-public] [PATCH] Handle __CTOR_LIST__ for clang
Hello. Bellow my signature is a copy of the explanation I sent to the list about why ca451a7 should be reverted. The issue is that different objects are adding constructor pointers to a special section for it, and the CRT need to reliably find the beginning of that section. The CRT uses special symbols defined by the linker script, __CTOR_LIST and __DTOR_LIST__. But Martell says clang cannot understand linker scripts. Does clang produce any special symbols at the beginning or end of sections? Is there a way to make it do that? That would be handy. Martell's code as presented at the beginning of this thread could work too, and putting it in a separate object file just for clang seems like a good idea. I think Martell's patch is relying on sections to be sorted in alphabetical order. --David Grayson -- Hello. Commit ca451a7a45d4876065edc6755f8aab8095914b04 caused issue #1104 in MSYS2, where basic C++ programs stopped working, probably because constructors were not called: https://github.com/Alexpux/MINGW-packages/issues/1104 If you compile a simple C++ hello world program, you can run the following command on it to see where the relevant symbols are getting placed: objdump -t prog.exe | egrep 'TOR_LIST|dtors|ctors' On my machine, using a 64-bit toolchain, I'm seeing that __CTOR_LIST__ is at 0x1e60 while __MINGW_CTOR_LIST__ is at 0x1e70. That is a difference of 16 bytes, so there are two constructors that wouldn't get run if you choose to use __MINGW_CTOR_LIST__ as the starting point for your loop that calls all the constructors. There is also a discrepancy for the destructors. The symbols __CTOR_LIST__ and __DTOR_LIST__ are actually defined in the linker script. My evidence for that is that if I compile a C++ program with "-Wl,-verbose", the default linker script is printed, and it has these lines to define __CTOR_LIST__ and __DTOR_LIST__ properly: . = ALIGN(8); ___CTOR_LIST__ = .; __CTOR_LIST__ = . ; LONG (-1); LONG (-1);*(.ctors); *(.ctor); *(SORT(.ctors.*)); LONG (0); LONG (0); ___DTOR_LIST__ = .; __DTOR_LIST__ = . ; LONG (-1); LONG (-1); *(.dtors); *(.dtor); *(SORT(.dtors.*)); LONG (0); LONG (0); *(.fini) The statement "___CTOR_LIST__ = ." tells the linker to define a symbol named ___CTOR_LIST__ at the current location (.). Then it puts some padding data, and then it puts all the constructors, and then it puts a null terminator. In contrast, the newly-introduced symbols __MINGW_CTOR_LIST__ and __MINGW_DTOR_LIST__ do not work properly because they were not placed in the right locations using a linker script. They were just defined as static variables in a particular section. Martell, I gather that you were working on some clang-based toolchain and you had trouble because __CTOR_LIST__ and __DTOR_LIST__ were not defined. Could you solve your issue by defining them in your linker script or something? I think commit ca451a7a45d4876065edc6755f8aab8095914b04 can be reverted. --David On Fri, Aug 4, 2017 at 11:34 AM, Martin Storsjö wrote: > On Thu, 3 Aug 2017, Martell Malone wrote: > >> Hey Martin, >> >> Glad to see you following up on my various LLVM adventures :) >> >> From what I remember the initialization is done in >> mingw-w64/crt/gccmain.c. >> I believe it may be possible to add this code and not make is clang >> specific. >> >> Before the iteration loop check in __do_global_ctors >> and __do_global_dtors check if nptrs+1 is equal to -1 and if so just bump >> the counter and continue. >> This would mean that programs linked with LD would have an extra 2 >> pointers >> in the table but it should be fine otherwise. >> >> Not sure how others would feel about this though. > > > Without having looked closer into this yet, I guess this is kinda what you > attempted in ca451a7a45d4876065edc6755f8aab8095914b04, which later was > reverted in 5981c0281b1f65b8f9b38b13f504f8af3f6ff209? So I guess that would > be a decent starting point, but trying to fix whatever that attempt broke? > > // Martin > > > -- > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > ___ > Mingw-w64-public mailing list > Mingw-w64-public@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/mingw-w64-public -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [PATCH 0/2] Add 'Windows Animation Manager' classes/interfaces
Try sending it as ".txt" file and make sure your MIME-type is something like text/plain. --David On Thu, Jul 13, 2017 at 11:29 AM, The Canadian Bacon wrote: > You're missing your attachment on this one. > > On Jul 13, 2017 11:05 AM, "Ruslan Garipov" wrote: > >> >> This is a series of commits that introduces [Windows Animation Manager] >> [1] (WAM) support into MinGW-w64. WAM is a COM based framework, and I >> created IDL and header files from scratch, since I did not find the >> files in Wine. >> >> I created 'uianimation.idl' file with 'genidl' tool from >> 'UIAnimation.dll' library from Microsoft Windows 10 SKU. The result IDL >> file was then slightly modified (I replaced some keywords in a way >> 'widl' would "understand" the file and remove some typedefs that may >> cause compilation errors). Then I generated 'uianimation.h' with 'widl' >> compiler from the updated 'uianimation.idl'. The result header >> 'uianimation.h' was not modified after that. >> >> I have tried to send those changes as one commit, but I ended up with >> patch size limitation on mingw-w64 `public' mailing list. I couldn't >> send the signle-commit-patch since e-mail with that patch slightly >> exceeded 512 KB. As it was advised on mingw-w64 IRC chat, I split the >> patch on to two parts. >> >> There are some whitespace errors in the patch, but they appear because >> such errors exist in the original Makefiles. I just "repeated" them. >> >> Please review. >> >> [1]: >> https://msdn.microsoft.com/en-us/library/windows/desktop/dd3 >> 71981(v=vs.85).aspx >> "Windows Animation Manager" >> >> Ruslan Garipov (2): >> Add 'Windows Animation Manager' header file >> Add 'Windows Animation Manager' IDL file >> >> mingw-w64-crt/Makefile.am | 18 +- >> mingw-w64-crt/Makefile.in | 56 +- >> mingw-w64-crt/libsrc/uianimation-uuid.c | 44 + >> mingw-w64-headers/Makefile.am |1 + >> mingw-w64-headers/Makefile.in |1 + >> mingw-w64-headers/include/uianimation.h | 7325 >> + >> mingw-w64-headers/include/uianimation.idl | 1291 + >> 7 files changed, 8718 insertions(+), 18 deletions(-) >> create mode 100644 mingw-w64-crt/libsrc/uianimation-uuid.c >> create mode 100644 mingw-w64-headers/include/uianimation.h >> create mode 100644 mingw-w64-headers/include/uianimation.idl >> >> >> >> >> >> -- >> Check out the vibrant tech community on one of the world's most >> engaging tech sites, Slashdot.org! http://sdm.link/slashdot >> ___ >> Mingw-w64-public mailing list >> Mingw-w64-public@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public >> > -- > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > ___ > Mingw-w64-public mailing list > Mingw-w64-public@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/mingw-w64-public -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Default _WIN32_WINNT version too low?
Riot, do you work for Riot Games? Anyway, in this patch, the line of code being changed is guarded by #ifndef _WIN32_WINNT. So if you define _WIN32_WINNT yourself, this patch will have no effect on you. (I'm assuming that the value of _WIN32_WINNT does not affect how the MinGW libraries are compiled, and it only affects what features are available in the header files.) --David On Mon, Jun 12, 2017 at 10:36 AM, Riot wrote: > I'd like to humbly request a hold on this. > > If it's not broken, why fix it? > > I've been happy to be able to tell our customers that our software works on > win XP (SP2) for a long while; and I don't see anything that's changed that > should require us to end that support. When we surveyed last year, several > percent of our users still used XP, and we don't really want to leave them > out in the cold without good reason. Building our own mingw just to > configure it with a lower default support version is out of the question > with our workflow, unfortunately. > > I don't see this as a constructive change, as it doesn't appear to actually > improve anything for anybody. Can we reconsider? > > > Regards, > Riot > > > On 12 June 2017 at 18:02, Liu Hao wrote: > >> On 2017/6/12 23:17, Martell Malone wrote: >> >>> In that case, >>> I think the best course of immediate action is to bump to Windows 7 as Kai >>> suggested. >>> If someone has the time to implement a configure option for changing this >>> default like Ruben suggest that would be a great. >>> Here is a patch for the former. >>> Please Review >>> >>> diff --git a/mingw-w64-headers/crt/_mingw.h.in b/mingw-w64-headers/crt/_ >>> mingw.h.in >>> index 2742b115..03de2212 100644 >>> --- a/mingw-w64-headers/crt/_mingw.h.in >>> +++ b/mingw-w64-headers/crt/_mingw.h.in >>> @@ -222,7 +222,7 @@ limitations in handling dllimport attribute. */ >>> #ifndef _WIN32_WINNT >>> -#define _WIN32_WINNT 0x502 >>> +#define _WIN32_WINNT 0x601 >>> #endif >>> #ifndef _INT128_DEFINED >>> >>> Upvote for this. OK for master? >> >> -- >> Best regards, >> LH_Mouse >> >> >> >> >> -- >> Check out the vibrant tech community on one of the world's most >> engaging tech sites, Slashdot.org! http://sdm.link/slashdot >> ___ >> Mingw-w64-public mailing list >> Mingw-w64-public@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public >> > -- > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > ___ > Mingw-w64-public mailing list > Mingw-w64-public@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/mingw-w64-public -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] static lib/Visual Studio problem
I'd encourage you to try the mingw-w64 route. If you use mingw-w64 and GCC, you won't have to worry about the licensing restrictions Microsoft puts on Visual Studio, which have changed over the years. The mingw-w64 project provides a lot of the headers and functions that Visual Studio has, and they always accept patches to add missing headers or functions on this mailing list. In fact, I've been able to compile two different pieces of pretty involved Microsoft sample code using mingw-w64 (usbview and devcon). --David On Wed, Jun 7, 2017 at 6:35 AM, Brad Garton wrote: > Aha -- this was what I feared would be the case. I'll start porting all > the code into VS and tracking down all the missing headers and functions, > oh joy. > > Thanks for the help, everyone! > > brad > > > On Wed, Jun 7, 2017 at 6:50 AM, Mateusz Mikuła wrote: > >> > However, once I try to use some more c++ features, I get the >> > following >> > error, and it seems to be associated with the compiled object files >> > themselves: >> > >> > "invalid or corrupt file: no symbol for COMDAT section ..." (and a >> > hex >> > address). >> >> It's not possible to mix static libstdc++ with Microsoft C++ runtime. >> In fact even mingw-w64 based Clang doesn't play nicely with static >> libstdc++ http://lists.llvm.org/pipermail/cfe-dev/2017-April/053530.htm >> l >> >> -- >> Check out the vibrant tech community on one of the world's most >> engaging tech sites, Slashdot.org! http://sdm.link/slashdot >> ___ >> Mingw-w64-public mailing list >> Mingw-w64-public@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public >> >> > -- > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > ___ > Mingw-w64-public mailing list > Mingw-w64-public@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/mingw-w64-public -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] static lib/Visual Studio problem
C++ has no standard ABI, so it is unlikely that you will be able to mix C++ binaries that come from different compilers like that. I'm not sure what the COMDAT error means, though. Why do you want to build your application using both Visual Studio and MinGW? Why not pick one and stick with it? --David On Tue, Jun 6, 2017 at 5:07 PM, Brad Garton wrote: > Hello mingw list -- > > I'm a total newbie to this list, and I'm not even sure it's active, but > I've googled a lot and can't find much information so I thought I'd try a > post here. > > I'm porting a large, unix-ey c/c++ package to Windows and I'm attempting to > compile a static lib that I can access in Visual Studio. For standard C > functions (even in c++ files), the lib (.a) I build with mingw works with > no problems. > > However, once I try to use some more c++ features, I get the following > error, and it seems to be associated with the compiled object files > themselves: > > "invalid or corrupt file: no symbol for COMDAT section ..." (and a hex > address). > > I've tried a number of different compilation flags, both in the mingw build > and the Visual Studio IDE, but no luck. I'm worried that there is a > fundamental incompatibility between g++ and MSVC. I wish there were an > option for "nm" or a libtool that would help me fix this. > > Any ideas? > > thanks -- > > Brad Garton > Columbia University Computer Music Center > -- > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > ___ > Mingw-w64-public mailing list > Mingw-w64-public@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/mingw-w64-public -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] C++ cout executable size
I was able to reproduce your problem. The issue is that you declared
a variable named stdout, which is a name used by the C standard. Just
rename that variable.
--David
On Sun, Jun 4, 2017 at 8:31 AM, bob by wrote:
> 2017-06-02 15:47 GMT+04:00 bob by
>
>> Can somebody here write a replacement for the standard cout, that will be
>> able to print strings and integers, and internally will just redirect to
>> puts and itoa? I'm only starting with C++, I'm not sure how to do it.
>>
>
> So, I'm trying to do this, This code seems to more or less work, but adding
> #include causes compile error at the HANDLE. Error says
> "declaration of _imp__iob as array of references".
>
> I kind of want to try out std::string, even though I don't know how it's
> different from char*.
>
> #include
>
> class cout_c
> {
> public:
> HANDLE stdout;
> void init()
> {
> stdout = GetStdHandle(STD_OUTPUT_HANDLE);
> }
> cout_c& operator<<(char* s)
> {
> WriteFile(stdout, s, strlen(s), NULL, NULL);
> return *this;
> }
> };
>
> cout_c cout;
>
> int main()
> {
> cout.init();
> cout << "1234567890";
> }
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> Mingw-w64-public mailing list
> Mingw-w64-public@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] C++ cout executable size
On Thu, Jun 1, 2017 at 11:49 AM, bob by wrote: > I linked all libraries statically, before that it depended on > libgcc_s_dw2-1.dll and libwinpthread-1.dll, and probably something > else too. It was around 500 KiB originally, now it is almost 1000 KiB. if your program depends on those DLLs, it means that the libaries provided by those DLLs were not linked in statically. A DLL is a dynamic shared object that gets loaded at runtime, while a static library is something that gets included into your EXE at link time and makes your EXE bigger. > Here is the output of my g++ -v OK, so you are using GCC 6.3.0, provided by the MSYS2 project. You can see how that version of GCC was built and track down its source code by looking at the build script here: https://github.com/Alexpux/MINGW-packages/tree/master/mingw-w64-gcc > Is it possible to make something that will look like cout << "some > string", but will just redirect to printf internally and be more > lightweight? I'm very new to C++ to mess with runtime by myself. Sure, you can define your own simple class that overrides the left shift operator and does arbitrary stuff with the arguments. C++ method overloading would allow you to define different overloads of the operator that handle the printing of different data types. I don't think saving a megabyte of executable size is enough to justify that effort, especially when you could save that size by using printf. Also, by making your own cout, you make it harder for other C++ programmers to understand and modify your code. --David -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] C++ cout executable size
Also, did you remember to run the binutils "strip" utility on your executable before deciding it was huge? --David On Thu, Jun 1, 2017 at 10:54 AM, David Grayson wrote: > How huge is "weirdly huge"? Does your executable depend on any MinGW > DLLs, like libstdc++-6.dll? > > The code in the "std" namespace is generally provided by libstdc++v3, > which is a component of GCC and can be found in the GCC source: > ftp://ftp.gnu.org/gnu/gcc/ You haven't said what version of GCC you > are using or what distribution of mingw-w64, so it's hard to point you > to the exact source. > > I'd recommend using printf, like those other people you talked to. > The code for that is provided by Microsoft in msvcrt.dll so it won't > be part of your executable. > > --David > > On Thu, Jun 1, 2017 at 9:41 AM, bob by wrote: >> Hello. Wrote my hello world in C++, but executable size is weirdly huge. >> >> Can I get a lightweight replacement for the cout << operator? People >> recommend to just use printf instead, but maybe there is a way. >> >> By the way, where can I get source code of std? I'd like to see how it >> works in debugger. >> -- >> Check out the vibrant tech community on one of the world's most >> engaging tech sites, Slashdot.org! http://sdm.link/slashdot >> ___ >> Mingw-w64-public mailing list >> Mingw-w64-public@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] C++ cout executable size
How huge is "weirdly huge"? Does your executable depend on any MinGW DLLs, like libstdc++-6.dll? The code in the "std" namespace is generally provided by libstdc++v3, which is a component of GCC and can be found in the GCC source: ftp://ftp.gnu.org/gnu/gcc/ You haven't said what version of GCC you are using or what distribution of mingw-w64, so it's hard to point you to the exact source. I'd recommend using printf, like those other people you talked to. The code for that is provided by Microsoft in msvcrt.dll so it won't be part of your executable. --David On Thu, Jun 1, 2017 at 9:41 AM, bob by wrote: > Hello. Wrote my hello world in C++, but executable size is weirdly huge. > > Can I get a lightweight replacement for the cout << operator? People > recommend to just use printf instead, but maybe there is a way. > > By the way, where can I get source code of std? I'd like to see how it > works in debugger. > -- > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > ___ > Mingw-w64-public mailing list > Mingw-w64-public@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/mingw-w64-public -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [PATCH 2/2] sal.h: Disable __in and __out macros when using libstdc++.
The boolean logic in the patch looks wrong to me. You're going to end up disabling __in and __out for all GCC and Clang programs regardless of what language they use because __GNUC__ will be defined. Seems like this would be better: #if defined(__cplusplus) && defined(__GNUC__) // Don't define __in and __out because they conflict with libstdc++. #else #define __in #define __out #endif --David On Mon, May 29, 2017 at 12:43 PM, Jacek Caban wrote: > I've seen a very good news that a fix to libstdc++ is on its way and that's > great. However, we need to support already released versions as well. That's > why I propose this patch. Ideally, we'd use __GLIBCXX__ macro, but it's not > available without including any standard header and sal.h is not a good > place to do that. In the future, when libstdc++ is fixed, we may change > guards to be version-dependent. > > Signed-off-by: Jacek Caban > --- > mingw-w64-headers/include/sal.h | 8 +++- > 1 file changed, 7 insertions(+), 1 deletion(-) > > > > -- > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > ___ > Mingw-w64-public mailing list > Mingw-w64-public@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/mingw-w64-public > -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [PATCH] Add flag for symlink creation by unprivileged users
Oops, there's no attachment. Try sending it with a MIME type of text/plain so SourceForge does not eat it; you might have to add a .txt extension to it to make your mail client do that. --David On Sat, May 27, 2017 at 7:51 PM, Samuel Leslie wrote: > Sounds like I've misinterpreted the correct usage of > VALID_SYMBOLIC_LINK_FLAGS. Apologies! I've attached an amended patch in the > event that's helpful. > > > Kind regards, > Samuel Leslie > > -Original Message- > From: Liu Hao [mailto:lh_mo...@126.com] > Sent: Sunday, 28 May 2017 8:35 AM > To: mingw-w64-public@lists.sourceforge.net; JonY > Subject: Re: [Mingw-w64-public] [PATCH] Add flag for symlink creation by > unprivileged users > > On 2017/5/27 21:35, JonY wrote: >> On 05/27/2017 11:14 AM, Samuel Leslie wrote: >>> The MSDN documentation doesn't appear to have been updated yet: >>> https://msdn.microsoft.com/en-us/library/windows/desktop/aa363866(v=v >>> s.85).aspx >>> >>> But you can find the details on the official developer blog: >>> https://blogs.windows.com/buildingapps/2016/12/02/symlinks-windows-10 >>> / >>> >> >> Patch looks good. > I don't think so... > > ``` > C:\Program Files (x86)\Windows Kits>grep -FnrI VALID_SYMBOLIC_LINK_FLAGS > 10/Include/10.0.14393.0/um/WinBase.h:8636:#define > VALID_SYMBOLIC_LINK_FLAGS SYMBOLIC_LINK_FLAG_DIRECTORY // & whatever other > flags we think of! > 8.1/Include/um/WinBase.h:8515:#define VALID_SYMBOLIC_LINK_FLAGS > SYMBOLIC_LINK_FLAG_DIRECTORY // & whatever other flags we think of! > ``` > > It is the definition of `SYMBOLIC_LINK_FLAG_ALLOW_UNPRIVILEGED_CREATE` > that looks good. The definition of `VALID_SYMBOLIC_LINK_FLAGS` should be left > intact. > > > -- > Best regards, > LH_Mouse > > > -- > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > ___ > Mingw-w64-public mailing list > Mingw-w64-public@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/mingw-w64-public > -- > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > ___ > Mingw-w64-public mailing list > Mingw-w64-public@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/mingw-w64-public -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [PATCH] comment out '__in' and '__out' from driverspecs.h for compatibility with libstdc++
On Wed, May 17, 2017 at 7:30 AM, Kai Tietz wrote: > This sed command is nice, but nothing to be recommended for our users. > Driver buiding is for sure the more rare case, and most users won't be > interested in that pretty much. For those which are, this might be a > way. > > Once again, why we include by default driverspecs.h ? Is that of any > meaning, beside for people using ddk? The reason to include driverspecs.h from specstrings.h is because the official Microsoft version does so (I thought you knew that, so maybe I'm the one who is missing something here). I'm looking into it more now. There are comments at the top of Microsoft's driverspecs.h that explain that kernelspecs.h and driverspecs.h together are used to annotate drivers. But driverspecs.h contains annotations which are "appropriate to user space code, or which might appear in headers that are shared between user space and kernel space". So it seems to be that you don't have to be a driver developer to use driverspecs.h. One example of a user-space program that uses driverspecs.h is devcon, a Microsoft command-line utility that helps install and list drivers. It uses __drv_allocatesMem in some of its source code. It lives in the Windows-driver-samples repository on GitHub but it is not a driver: https://github.com/Microsoft/Windows-driver-samples/blob/master/setup/devcon/devcon.cpp#L360 But driverspecs.h should not be the main target of concern here, since the official driverspecs.h does not define __in or __out. It only mostly just defines things with the __drv prefix. Microsoft's sal.h is the header file that (unconditionally) defines __in and __out. But I don't understand the difference between those and _In_ and _Out_, and I can only find documentation for the latter pair, so it's a bit confusing. Now that I think about it again, given that driverspecs.h does not define __in or __out, I am actually in favor of Mateusz's patch now, because it will make mingw-w64 closer to the official Windows headers. +1 for Mateusz's patch. --David Grayson -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [PATCH] comment out '__in' and '__out' from driverspecs.h for compatibility with libstdc++
On Wed, May 17, 2017 at 4:10 AM, Kai Tietz wrote: > The best solution would be something like to include > driverspecs.h in specstring.h only, if user intends to use ddk. Is that how the real DDK works? When you don't have the DDK installed, you can still include specstrings.h but it somehow does not include driverspecs.h? --David Grayson -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [PATCH] comment out '__in' and '__out' from driverspecs.h for compatibility with libstdc++
Here's the sed command again, without bad line wrapping:
https://gist.github.com/DavidEGrayson/ee9796a900eedda3d6b7c8f2324793a4
--David
On Wed, May 17, 2017 at 7:08 AM, David Grayson wrote:
> A GCC maintainer has spoken up and said they will accept a patch to
> rename __in and __out to other things:
>
> https://gcc.gnu.org/ml/gcc-help/2017-05/msg00152.html
>
> As soon as I have a bit of free time, I will submit such a patch to
> them, though LH_Mouse might beat me to it.
>
> So in the long term, we can have __in and __out, and we can have
> compatibility with libstdc++v3. I'd rather not change mingw-w64.
>
> In the MSYS2 project, we've already dealt with this issue by
> generating a patch for libstdc++v3 using this command I put together:
>
> sed -ri 's/\b(__in|__out)\b/_&/g' $(egrep -rl '\b(__in|__out)\b'
> libstdc++-v3/{include,config})
>
> If you are compiling your own mingw-w64 toolchain, you should be
> capable of just running that line of code before building GCC to fix
> the name collision.
>
> If you are a user who is using a broken mingw-w64 toolchain, you
> should tell the people who built it about the line above, but in the
> meantime, you can edit driverspecs.h with a text editor and uncomment
> the lines that define __in and __out.
>
> So I think the status quo is totally fine.
>
> But if we do change mingw-w64, I can revert your change in my builds,
> and that works too, and it's just as easy as getting other toolchain
> builders to run the sed command. If we do change mingw-w64, what
> would be the timeline for reverting that change? Would we wait until
> the offending versions of libstdc++ have been replaced by fixed stable
> for versions for, say, 5 years?
>
> --David Grayson
>
> On Wed, May 17, 2017 at 6:18 AM, Mateusz wrote:
>> W dniu 2017-05-17 o 13:10, Kai Tietz pisze:
>>> Hello,
>>>
>>> I dislike such a change. As if somebody wants to driverspec.h, op
>>> will need these symbols defined. Otherwise build will badly fail.
>>> So this brings us back to the reasoning of this ... adding to
>>> specstrings.h the include of driverspecs.h. IMHO this shouldn't be
>>> done always. The best solution would be something like to include
>>> driverspecs.h in specstring.h only, if user intends to use ddk.
>>> Otherwise we shouldn't include this header at all.
>>>
>>> Any thoughts?
>>>
>>> Regards,
>>> Kai
>>
>> We could roll back commit [b7f44b].
>>
>> Now there are new commits and this should be fixed.
>>
>> Mateusz
>>
>>
>>
>>>
>>>
>>> 2017-05-17 12:34 GMT+02:00 Mateusz :
>>>> We really should do something with '__in' and '__out' from driverspecs.h.
>>>>
>>>> Please review.
>>>>
>>>>
>>>> --
>>>> Check out the vibrant tech community on one of the world's most
>>>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>>>> ___
>>>> Mingw-w64-public mailing list
>>>> Mingw-w64-public@lists.sourceforge.net
>>>> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
>>>>
>>>
>>> --
>>> Check out the vibrant tech community on one of the world's most
>>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>>> ___
>>> Mingw-w64-public mailing list
>>> Mingw-w64-public@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
>>>
>>
>>
>> --
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> ___
>> Mingw-w64-public mailing list
>> Mingw-w64-public@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [PATCH] comment out '__in' and '__out' from driverspecs.h for compatibility with libstdc++
A GCC maintainer has spoken up and said they will accept a patch to
rename __in and __out to other things:
https://gcc.gnu.org/ml/gcc-help/2017-05/msg00152.html
As soon as I have a bit of free time, I will submit such a patch to
them, though LH_Mouse might beat me to it.
So in the long term, we can have __in and __out, and we can have
compatibility with libstdc++v3. I'd rather not change mingw-w64.
In the MSYS2 project, we've already dealt with this issue by
generating a patch for libstdc++v3 using this command I put together:
sed -ri 's/\b(__in|__out)\b/_&/g' $(egrep -rl '\b(__in|__out)\b'
libstdc++-v3/{include,config})
If you are compiling your own mingw-w64 toolchain, you should be
capable of just running that line of code before building GCC to fix
the name collision.
If you are a user who is using a broken mingw-w64 toolchain, you
should tell the people who built it about the line above, but in the
meantime, you can edit driverspecs.h with a text editor and uncomment
the lines that define __in and __out.
So I think the status quo is totally fine.
But if we do change mingw-w64, I can revert your change in my builds,
and that works too, and it's just as easy as getting other toolchain
builders to run the sed command. If we do change mingw-w64, what
would be the timeline for reverting that change? Would we wait until
the offending versions of libstdc++ have been replaced by fixed stable
for versions for, say, 5 years?
--David Grayson
On Wed, May 17, 2017 at 6:18 AM, Mateusz wrote:
> W dniu 2017-05-17 o 13:10, Kai Tietz pisze:
>> Hello,
>>
>> I dislike such a change. As if somebody wants to driverspec.h, op
>> will need these symbols defined. Otherwise build will badly fail.
>> So this brings us back to the reasoning of this ... adding to
>> specstrings.h the include of driverspecs.h. IMHO this shouldn't be
>> done always. The best solution would be something like to include
>> driverspecs.h in specstring.h only, if user intends to use ddk.
>> Otherwise we shouldn't include this header at all.
>>
>> Any thoughts?
>>
>> Regards,
>> Kai
>
> We could roll back commit [b7f44b].
>
> Now there are new commits and this should be fixed.
>
> Mateusz
>
>
>
>>
>>
>> 2017-05-17 12:34 GMT+02:00 Mateusz :
>>> We really should do something with '__in' and '__out' from driverspecs.h.
>>>
>>> Please review.
>>>
>>>
>>> --
>>> Check out the vibrant tech community on one of the world's most
>>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>>> ___
>>> Mingw-w64-public mailing list
>>> Mingw-w64-public@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
>>>
>>
>> --
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> ___
>> Mingw-w64-public mailing list
>> Mingw-w64-public@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
>>
>
>
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> Mingw-w64-public mailing list
> Mingw-w64-public@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Fwd: Re: [PATCH] Include driverspecs.h in specstrings.h.
If I were a mingw-w64 committer, I probably wouldn't make that change,
but I am OK with it. An argument in favor of that change is that it
isn't too hard to just use sed or carefully-placed #defines to fix any
Microsoft-style code that uses __in and __out. (It's not ideal, but
not terrible.) And once we get libstdc++ to stop using those names,
we could undo the change.
And if we do change mingw-w64, I agree the way to do it is to comment
out the __in and __out lines in driverspecs.h, rather than reverting
the patch I posted at the beginning of this thread.
--David
On Mon, May 15, 2017 at 1:57 AM, Mateusz wrote:
> W dniu 2017-05-15 o 08:51, Liu Hao pisze:
>> On 2017/5/11 23:11, Kai Tietz wrote:
>>> I would prefer this too, but I don't believe that we can convince
>>> libstdc++ maintainers to modify their code for this. Sadly the MS'
>>> platform sdk defines a lot of stuff, which collides some times with
>>> some projects. We made about this already a lot of bad experiences
>>> ... especially in context of MIDL ... defining
>>> IN/OUT/INOUT/OPTIONAL/etc is really no clever move ...
>>> Nevertheless it might be worth a try to ask libstdc++ people for those
>>> __in A good argument (and bad one too) might be that the double
>>> underscore symbols are reserved to compilers/system headers. And
>>> well, C++ headers aren't really system headers, which is in general
>>> just a POV ;)
>> I suggest we comment out `__in` and `__out` from _driverspecs.h_. The
>> compatibility with GNU libstdc++ and LLVM libcxx is more essential than
>> that with Windows in my opinion.
>
> +1
>
>>
>> These macros are defined after including _windows.h_ from official
>> Windows SDK, as shown in this example:
>>
>>
>> E:\Desktop>cat test.c
>> #include
>> #include
>>
>> int main(){
>> #if defined(__in)
>> puts("__in is defined.");
>> #else
>> puts("__in is not defined.");
>> #endif
>> }
>>
>> E:\Desktop>cl test.c /nologo /Fea.exe
>> test.c
>>
>> E:\Desktop>cat test.c
>> #include
>> #include
>>
>> int main(){
>> #if defined(__in)
>> puts("__in is defined.");
>> #else
>> puts("__in is not defined.");
>> #endif
>> }
>>
>> E:\Desktop>cl test.c /nologo /Fe:a.exe
>> test.c
>>
>> E:\Desktop>a.exe
>> __in is defined.
>>
>> E:\Desktop>gcc test.c
>>
>> E:\Desktop>a.exe
>> __in is not defined.
>>
>>
>>
>
>
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> Mingw-w64-public mailing list
> Mingw-w64-public@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Fwd: Re: [PATCH] Include driverspecs.h in specstrings.h.
For anyone who is getting errors from the libstdc++ headers due to the
name conflicts for __in and __out, here are the commands you should
run when building GCC 6.3.0 to fix it:
cd libstdc++-v3
sed -i 's/\b__in\b/___in/g' \
include/ext/random.tcc \
include/ext/vstring.tcc \
include/std/utility \
include/std/tuple \
include/std/istream \
include/tr2/bool_set.tcc \
include/tr2/bool_set \
include/bits/basic_string.h \
include/bits/basic_string.tcc \
include/bits/locale_facets.h \
include/bits/istream.tcc \
include/tr1/utility \
include/tr1/tuple
sed -i 's/\b__out\b/___out/g' \
include/ext/random.tcc \
include/ext/algorithm \
include/ext/pb_ds/detail/debug_map_base.hpp \
include/std/ostream \
include/std/thread \
include/tr2/bool_set \
include/bits/ostream.tcc \
include/bits/regex.tcc \
include/bits/stl_algo.h \
include/bits/locale_conv.h \
include/bits/regex.h \
include/bits/ostream_insert.h \
include/tr1/regex \
include/parallel/algo.h \
include/parallel/set_operations.h \
include/parallel/multiway_merge.h \
include/parallel/unique_copy.h \
include/experimental/algorithm \
config/locale/dragonfly/c_locale.h \
config/locale/generic/c_locale.h \
config/locale/gnu/c_locale.h
--David
On Thu, May 11, 2017 at 9:55 AM, David Grayson wrote:
> Hello, gcc-help.
>
> There is an incompatibility between libstdc++ and the headers provided
> by Microsoft and mingw-w64, because libstdc++ uses __in as a parameter
> name in several places while the Microsoft headers define __in as a
> preprocessor macro as part of their Source Annotation Language.
>
> You can see several uses of __in in Microsoft-style code here:
>
> https://github.com/Microsoft/Windows-driver-samples/search?q=__in
>
> I would be willing to create, test, and submit a patch that changes
> libstdc++ to use ___in (with three underscores) to avoid this issue.
> I expect that to be a pretty safe change that doesn't break anything.
> Maybe I would add a test to help prevent this from happening in the
> future. Would the GCC maintainers consider accepting such a patch?
>
> Please note that I'm not trying to assign blame, I'm just trying to
> get Qt to compile with the latest mingw-w64 without using hacky
> workarounds.
>
> --David
>
> On Thu, May 11, 2017 at 7:29 AM, Liu Hao wrote:
>> On 2017/5/11 21:51, David Grayson wrote:
>>> Unfortunately, my patch seems to break several classes in libstdc++,
>>> preventing Qt from building. The problem is that driverspecs.h defines
>>> __in to be empty so we can compile Microsoft-type code that uses __in as a
>>> source annotation on function parameters while GCC's libstdc++ uses __in as
>>> the name of an input argument for many of its methods:
>>>
>>> $ egrep -lr '\b__in\b' /mingw32/include/
>>> /mingw32/include/c++/6.3.0/bits/basic_string.h
>>> /mingw32/include/c++/6.3.0/bits/basic_string.tcc
>>> /mingw32/include/c++/6.3.0/bits/istream.tcc
>>> /mingw32/include/c++/6.3.0/bits/locale_facets.h
>>> /mingw32/include/c++/6.3.0/ext/random.tcc
>>> /mingw32/include/c++/6.3.0/ext/vstring.tcc
>>> /mingw32/include/c++/6.3.0/istream
>>> /mingw32/include/c++/6.3.0/tr1/tuple
>>> /mingw32/include/c++/6.3.0/tr1/utility
>>> /mingw32/include/c++/6.3.0/tr2/bool_set
>>> /mingw32/include/c++/6.3.0/tr2/bool_set.tcc
>>> /mingw32/include/c++/6.3.0/tuple
>>> /mingw32/include/c++/6.3.0/utility
>>>
>>> One of the errors I get looks like this:
>>>
>>> /nix/.../include/c++/6.3.0/utility:208:57: error: no matching function for
>>> call to 'move()'
>>> { return __pair_get<_Int>::__move_get(std::move(__in)); }
>>>
>>> I don't think this is necessarily a problem with mingw-w64, or a problem
>>> with that patch. Adrien Nader's attitude on this mailing list in
>>> 2015-11-03 was "Really, there's a platform and software is built on top of
>>> it; it is that software that is supposed to adapt to the platform."
>>> Microsoft
>>> Windows and mingw-w64 are platforms that define __in to have a special
>>> meaning. The software built on that platform (libstdc++) should adapt to
>>> the platform.
>> I CC'd gcc-help. Hope it helps.
>> Anyway Windows headers are really a can of worms (think about the macros
>> `min` and `max` for example).
>>
>>> One odd thing is that our __in gets defined in driverspecs.h, while
>>> Microsoft defines their __in in sal.h. But specstrings.h (for both
>>> mingw-w64 and Microsoft) includes both sal.h and driverspecs.h so that
>>> shouldn't affect when the bug appears.
>> Both headers seem to be out of sync for years. I hope they can be
>> updated someday.
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Fwd: Re: [PATCH] Include driverspecs.h in specstrings.h.
Hello, gcc-help.
There is an incompatibility between libstdc++ and the headers provided
by Microsoft and mingw-w64, because libstdc++ uses __in as a parameter
name in several places while the Microsoft headers define __in as a
preprocessor macro as part of their Source Annotation Language.
You can see several uses of __in in Microsoft-style code here:
https://github.com/Microsoft/Windows-driver-samples/search?q=__in
I would be willing to create, test, and submit a patch that changes
libstdc++ to use ___in (with three underscores) to avoid this issue.
I expect that to be a pretty safe change that doesn't break anything.
Maybe I would add a test to help prevent this from happening in the
future. Would the GCC maintainers consider accepting such a patch?
Please note that I'm not trying to assign blame, I'm just trying to
get Qt to compile with the latest mingw-w64 without using hacky
workarounds.
--David
On Thu, May 11, 2017 at 7:29 AM, Liu Hao wrote:
> On 2017/5/11 21:51, David Grayson wrote:
>> Unfortunately, my patch seems to break several classes in libstdc++,
>> preventing Qt from building. The problem is that driverspecs.h defines
>> __in to be empty so we can compile Microsoft-type code that uses __in as a
>> source annotation on function parameters while GCC's libstdc++ uses __in as
>> the name of an input argument for many of its methods:
>>
>> $ egrep -lr '\b__in\b' /mingw32/include/
>> /mingw32/include/c++/6.3.0/bits/basic_string.h
>> /mingw32/include/c++/6.3.0/bits/basic_string.tcc
>> /mingw32/include/c++/6.3.0/bits/istream.tcc
>> /mingw32/include/c++/6.3.0/bits/locale_facets.h
>> /mingw32/include/c++/6.3.0/ext/random.tcc
>> /mingw32/include/c++/6.3.0/ext/vstring.tcc
>> /mingw32/include/c++/6.3.0/istream
>> /mingw32/include/c++/6.3.0/tr1/tuple
>> /mingw32/include/c++/6.3.0/tr1/utility
>> /mingw32/include/c++/6.3.0/tr2/bool_set
>> /mingw32/include/c++/6.3.0/tr2/bool_set.tcc
>> /mingw32/include/c++/6.3.0/tuple
>> /mingw32/include/c++/6.3.0/utility
>>
>> One of the errors I get looks like this:
>>
>> /nix/.../include/c++/6.3.0/utility:208:57: error: no matching function for
>> call to 'move()'
>> { return __pair_get<_Int>::__move_get(std::move(__in)); }
>>
>> I don't think this is necessarily a problem with mingw-w64, or a problem
>> with that patch. Adrien Nader's attitude on this mailing list in
>> 2015-11-03 was "Really, there's a platform and software is built on top of
>> it; it is that software that is supposed to adapt to the platform."
>> Microsoft
>> Windows and mingw-w64 are platforms that define __in to have a special
>> meaning. The software built on that platform (libstdc++) should adapt to
>> the platform.
> I CC'd gcc-help. Hope it helps.
> Anyway Windows headers are really a can of worms (think about the macros
> `min` and `max` for example).
>
>> One odd thing is that our __in gets defined in driverspecs.h, while
>> Microsoft defines their __in in sal.h. But specstrings.h (for both
>> mingw-w64 and Microsoft) includes both sal.h and driverspecs.h so that
>> shouldn't affect when the bug appears.
> Both headers seem to be out of sync for years. I hope they can be
> updated someday.
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Fwd: Re: [PATCH] Include driverspecs.h in specstrings.h.
Oh, I thought we should just get libstdc++ to patch their project. I would
look for __in and any other badly-named parameters, and perhaps add a third
underscore to their names or something like that. In the long term, that
would be nicer, because then users can have Microsoft-style code and
libstdc++ code used in the same translation unit and they don't have to
remember to use a guard on the include.
--David
On Thu, May 11, 2017 at 7:24 AM, Kai Tietz wrote:
> Yes, that is a bit annoying ... sadly we can't do much about it.
>
> So I would suggest to add a guard to the include, so that it is
> user-defined, if this header should be included, or not.
> This might be a work-a-round for this, which should work for most.
>
> Regards,
> Kai
>
> 2017-05-11 15:51 GMT+02:00 David Grayson :
> > Unfortunately, my patch seems to break several classes in libstdc++,
> > preventing Qt from building. The problem is that driverspecs.h defines
> > __in to be empty so we can compile Microsoft-type code that uses __in as
> a
> > source annotation on function parameters while GCC's libstdc++ uses __in
> as
> > the name of an input argument for many of its methods:
> >
> > $ egrep -lr '\b__in\b' /mingw32/include/
> > /mingw32/include/c++/6.3.0/bits/basic_string.h
> > /mingw32/include/c++/6.3.0/bits/basic_string.tcc
> > /mingw32/include/c++/6.3.0/bits/istream.tcc
> > /mingw32/include/c++/6.3.0/bits/locale_facets.h
> > /mingw32/include/c++/6.3.0/ext/random.tcc
> > /mingw32/include/c++/6.3.0/ext/vstring.tcc
> > /mingw32/include/c++/6.3.0/istream
> > /mingw32/include/c++/6.3.0/tr1/tuple
> > /mingw32/include/c++/6.3.0/tr1/utility
> > /mingw32/include/c++/6.3.0/tr2/bool_set
> > /mingw32/include/c++/6.3.0/tr2/bool_set.tcc
> > /mingw32/include/c++/6.3.0/tuple
> > /mingw32/include/c++/6.3.0/utility
> >
> > One of the errors I get looks like this:
> >
> > /nix/.../include/c++/6.3.0/utility:208:57: error: no matching function
> for
> > call to 'move()'
> > { return __pair_get<_Int>::__move_get(std::move(__in)); }
> >
> > I don't think this is necessarily a problem with mingw-w64, or a problem
> > with that patch. Adrien Nader's attitude on this mailing list in
> > 2015-11-03 was "Really, there's a platform and software is built on top
> of
> > it; it is that software that is supposed to adapt to the platform."
> Microsoft
> > Windows and mingw-w64 are platforms that define __in to have a special
> > meaning. The software built on that platform (libstdc++) should adapt to
> > the platform.
> >
> > One odd thing is that our __in gets defined in driverspecs.h, while
> > Microsoft defines their __in in sal.h. But specstrings.h (for both
> > mingw-w64 and Microsoft) includes both sal.h and driverspecs.h so that
> > shouldn't affect when the bug appears.
> >
> > --David Grayson
> >
> > On Wed, May 10, 2017 at 9:44 AM, David Grayson
> > wrote:
> >
> >> Yeah, sorry, I only sent those patches to LH by mistake. Yes, I
> purposely
> >> used the same include guard name as Microsoft.
> >>
> >> --David
> >>
> >> On Wed, May 10, 2017 at 8:55 AM, Liu Hao wrote:
> >>
> >>>
> >>>
> >>>
> >>> Forwarded Message
> >>> Subject:Re: [Mingw-w64-public] [PATCH] Include driverspecs.h in
> >>> specstrings.h.
> >>> Date: Wed, 10 May 2017 08:24:25 -0700
> >>> From: David Grayson
> >>> To: Liu Hao
> >>>
> >>>
> >>>
> >>> OK, thanks. I've attached a new patch where the #include is after the
> >>> __cplusplus stuff.
> >>>
> >>> I also included a second patch that will add an include guard for
> >>> specstrings.h, since Microsoft seems to do that too.
> >>>
> >>> driverspecs.h is also missing an include guard but it is part of the
> >>> React DDK so I didn't want to mess around with editing at the moment.
> >>>
> >>> --David
> >>>
> >>> On Tue, May 9, 2017 at 9:07 PM, Liu Hao >>> lh_mo...@126.com>> wrote:
> >>>
> >>> On 2017/5/10 10:34, David Grayson wrote:
> >>>
> >>> This patch adds "#include " near the end of
> >>> specstrings.h,
> >>> because the same is done in Microsoft's version of
> >>>
Re: [Mingw-w64-public] Fwd: Re: [PATCH] Include driverspecs.h in specstrings.h.
Unfortunately, my patch seems to break several classes in libstdc++,
preventing Qt from building. The problem is that driverspecs.h defines
__in to be empty so we can compile Microsoft-type code that uses __in as a
source annotation on function parameters while GCC's libstdc++ uses __in as
the name of an input argument for many of its methods:
$ egrep -lr '\b__in\b' /mingw32/include/
/mingw32/include/c++/6.3.0/bits/basic_string.h
/mingw32/include/c++/6.3.0/bits/basic_string.tcc
/mingw32/include/c++/6.3.0/bits/istream.tcc
/mingw32/include/c++/6.3.0/bits/locale_facets.h
/mingw32/include/c++/6.3.0/ext/random.tcc
/mingw32/include/c++/6.3.0/ext/vstring.tcc
/mingw32/include/c++/6.3.0/istream
/mingw32/include/c++/6.3.0/tr1/tuple
/mingw32/include/c++/6.3.0/tr1/utility
/mingw32/include/c++/6.3.0/tr2/bool_set
/mingw32/include/c++/6.3.0/tr2/bool_set.tcc
/mingw32/include/c++/6.3.0/tuple
/mingw32/include/c++/6.3.0/utility
One of the errors I get looks like this:
/nix/.../include/c++/6.3.0/utility:208:57: error: no matching function for
call to 'move()'
{ return __pair_get<_Int>::__move_get(std::move(__in)); }
I don't think this is necessarily a problem with mingw-w64, or a problem
with that patch. Adrien Nader's attitude on this mailing list in
2015-11-03 was "Really, there's a platform and software is built on top of
it; it is that software that is supposed to adapt to the platform." Microsoft
Windows and mingw-w64 are platforms that define __in to have a special
meaning. The software built on that platform (libstdc++) should adapt to
the platform.
One odd thing is that our __in gets defined in driverspecs.h, while
Microsoft defines their __in in sal.h. But specstrings.h (for both
mingw-w64 and Microsoft) includes both sal.h and driverspecs.h so that
shouldn't affect when the bug appears.
--David Grayson
On Wed, May 10, 2017 at 9:44 AM, David Grayson
wrote:
> Yeah, sorry, I only sent those patches to LH by mistake. Yes, I purposely
> used the same include guard name as Microsoft.
>
> --David
>
> On Wed, May 10, 2017 at 8:55 AM, Liu Hao wrote:
>
>>
>>
>>
>> Forwarded Message
>> Subject:Re: [Mingw-w64-public] [PATCH] Include driverspecs.h in
>> specstrings.h.
>> Date: Wed, 10 May 2017 08:24:25 -0700
>> From: David Grayson
>> To: Liu Hao
>>
>>
>>
>> OK, thanks. I've attached a new patch where the #include is after the
>> __cplusplus stuff.
>>
>> I also included a second patch that will add an include guard for
>> specstrings.h, since Microsoft seems to do that too.
>>
>> driverspecs.h is also missing an include guard but it is part of the
>> React DDK so I didn't want to mess around with editing at the moment.
>>
>> --David
>>
>> On Tue, May 9, 2017 at 9:07 PM, Liu Hao > lh_mo...@126.com>> wrote:
>>
>> On 2017/5/10 10:34, David Grayson wrote:
>>
>> This patch adds "#include " near the end of
>> specstrings.h,
>> because the same is done in Microsoft's version of
>> specstrings.h. With
>> this patch, I am able to build Microsoft's devcon utility without
>> modification. Thanks!
>>
>> You must `#include` that header AFTER the `#ifdef __cplusplus ...
>> #endif` block.
>>
>> Anyway, this header seems short of a header guard. I shall ask
>> someone for sure.
>>
>> -- Best regards,
>> LH_Mouse
>>
>>
>>
>>
>> --
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> ___
>> Mingw-w64-public mailing list
>> Mingw-w64-public@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
>>
>>
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Fwd: Re: [PATCH] Include driverspecs.h in specstrings.h.
Yeah, sorry, I only sent those patches to LH by mistake. Yes, I purposely used the same include guard name as Microsoft. --David On Wed, May 10, 2017 at 8:55 AM, Liu Hao wrote: > > > > Forwarded Message > Subject:Re: [Mingw-w64-public] [PATCH] Include driverspecs.h in > specstrings.h. > Date: Wed, 10 May 2017 08:24:25 -0700 > From: David Grayson > To: Liu Hao > > > > OK, thanks. I've attached a new patch where the #include is after the > __cplusplus stuff. > > I also included a second patch that will add an include guard for > specstrings.h, since Microsoft seems to do that too. > > driverspecs.h is also missing an include guard but it is part of the React > DDK so I didn't want to mess around with editing at the moment. > > --David > > On Tue, May 9, 2017 at 9:07 PM, Liu Hao lh_mo...@126.com>> wrote: > > On 2017/5/10 10:34, David Grayson wrote: > > This patch adds "#include " near the end of > specstrings.h, > because the same is done in Microsoft's version of > specstrings.h. With > this patch, I am able to build Microsoft's devcon utility without > modification. Thanks! > > You must `#include` that header AFTER the `#ifdef __cplusplus ... > #endif` block. > > Anyway, this header seems short of a header guard. I shall ask > someone for sure. > > -- Best regards, > LH_Mouse > > > > > -- > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > ___ > Mingw-w64-public mailing list > Mingw-w64-public@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/mingw-w64-public > > -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
[Mingw-w64-public] [PATCH] Include driverspecs.h in specstrings.h.
This patch adds "#include " near the end of specstrings.h,
because the same is done in Microsoft's version of specstrings.h. With
this patch, I am able to build Microsoft's devcon utility without
modification. Thanks!
--David Grayson
From bbe97312dabdbd7200b337ad8f8232786ae77c4e Mon Sep 17 00:00:00 2001
From: David Grayson
Date: Tue, 9 May 2017 09:15:29 -0700
Subject: [PATCH] specstrings.h: Include driverspecs.h near the bottom.
That's what the Microsoft header does, and their devcon utility
depends on it.
---
mingw-w64-headers/include/specstrings.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/mingw-w64-headers/include/specstrings.h
b/mingw-w64-headers/include/specstrings.h
index 485b4330..5c35 100644
--- a/mingw-w64-headers/include/specstrings.h
+++ b/mingw-w64-headers/include/specstrings.h
@@ -325,6 +325,8 @@ extern "C" {
#endif
#endif /* DECLSPEC_ADDRSAFE */
+#include
+
#ifdef __cplusplus
}
#endif
--
2.12.1
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [PATCH] guiddef.h: Use __declspec(selectany) on GUID declarations.
Hello, Mateusz, LH_Mouse. Another point against my patch and Mateusz's patch is that applying __declspec(selectany) to a declaration is "incorrect" according to MSDN: https://msdn.microsoft.com/en-us/library/5tkz6s71.aspx The clang people have some handy notes in their test suite about how clang and MSVC treat selectany: https://github.com/llvm-mirror/clang/blob/master/test/SemaCX X/attr-selectany.cpp I tested Visual Studio 2017 and GCC 6.3.0 (from MSYS2. for x86_64) today to see if they have the multiple definition error that caused me to originally post my patch, where selectany on a variable definition is ignored if the variable has a previous declaration without selectany. I tested both C and C++ source files. The results were: GCC with C: has the issue GCC with C++: works Visual Studio with C: works Visual Studio with C++ source: works So now I agree with LH_Mouse that what we are seeing is an issue with GCC and the GCC maintainers should fix it. I wouldn't call it a bug because I don't think there is a standard for non-standard language extensions like __declspec. I disagree with LH_Mouse's absolutist attitude that "we are unable to fix it afterall". I think there are other places where mingw-w64 works around quirks or missing features in GCC. Per LH_Mouse's suggestion, I tried using -DINITGUID with GCC 6.3.0 in my own build environment to compile UsbView. However, that does not work because you get multiple definition errors. GCC, like MSVC, does not let you have multiple definitions of a variable in the same transation unit even if they are marked with selectany. I guess, for now, people using GCC 6+ can apply my patch to their mingw if they care, and eventually maybe we can fix GCC so it's not necessary. --David On Wed, May 3, 2017 at 2:14 PM, Mateusz wrote: > We could consider define DECLSPEC_SELECTANY to __attribute__((weak)) for > old GCC. > > Patch for this attached. > > W dniu 2017-05-03 o 17:19, David Grayson pisze: > > By the way, it's really not clear to me what specific solution you are > > proposing when you say "ensure each GUID is defined only once" but I'm > > imagining it will introduce new incompatibilities/quirks that people have > > to worry about when switching between Visual Studio and mingw-w64, > because > > you would have to prevent any GUID definitions from being emitted by > header > > files. > > > > --David > > > > On Wed, May 3, 2017 at 8:12 AM, David Grayson > > wrote: > > > >>> It sounds like guiddef.h should probably check the GCC major version. > >>>> Based on the tests people have reported in this thread, I would guess > >>> that > >>>> for GCC 6 and above the selectany attribute on the declaration is > >>> required, > >>>> while on GCC 5 and below the selectany attribute on the declaration is > >>>> forbidden. Or we could get fancy and add a test to the configure > script > >>> to > >>>> figure out which is the case. > >>> Both require citation from GCC documentation. But neither is an optimal > >>> solution IMHO. I suggest we ensure each GUID is defined only once then > >>> remove that attribute completely. > >>> > >> > >> When you say "optimal", what are you optimizing for? > >> > >> I'm trying to optimize for being able to port code from Visual Studio to > >> mingw-w64. Microsoft has example code (UsbView) that has a header file > >> that includes the windows.h, followed by initguid.h, followed by > >> winioctl.h. You can see the header file here: > >> > >> https://github.com/Microsoft/Windows-driver-samples/blob/ > >> master/usb/usbview/uvcview.h > >> > >> The UsbView code uses that header file in several different translation > >> units, so you end up having a bunch of duplicate GUID definitions for > all > >> the GUIDs defined in winioctl.h, like GUID_DEVINTERFACE_DISK. To > prevent > >> multiple definition errors, the Microsoft header files using the > selectany > >> attribute. > >> > >> I don't know why Microsoft engineered such a complicated solution for > >> defining GUIDs, but they did, and I would think we should try to make > our > >> header files compatible with it. If it just takes a few preprocessor if > >> statements that check the GCC version, that seems OK. > >> > >> --David > >> > > > -- > > Check out the vibrant tech community on one of the world'
Re: [Mingw-w64-public] [PATCH] guiddef.h: Use __declspec(selectany) on GUID declarations.
By the way, it's really not clear to me what specific solution you are proposing when you say "ensure each GUID is defined only once" but I'm imagining it will introduce new incompatibilities/quirks that people have to worry about when switching between Visual Studio and mingw-w64, because you would have to prevent any GUID definitions from being emitted by header files. --David On Wed, May 3, 2017 at 8:12 AM, David Grayson wrote: > > It sounds like guiddef.h should probably check the GCC major version. >> > Based on the tests people have reported in this thread, I would guess >> that >> > for GCC 6 and above the selectany attribute on the declaration is >> required, >> > while on GCC 5 and below the selectany attribute on the declaration is >> > forbidden. Or we could get fancy and add a test to the configure script >> to >> > figure out which is the case. >> Both require citation from GCC documentation. But neither is an optimal >> solution IMHO. I suggest we ensure each GUID is defined only once then >> remove that attribute completely. >> > > When you say "optimal", what are you optimizing for? > > I'm trying to optimize for being able to port code from Visual Studio to > mingw-w64. Microsoft has example code (UsbView) that has a header file > that includes the windows.h, followed by initguid.h, followed by > winioctl.h. You can see the header file here: > > https://github.com/Microsoft/Windows-driver-samples/blob/ > master/usb/usbview/uvcview.h > > The UsbView code uses that header file in several different translation > units, so you end up having a bunch of duplicate GUID definitions for all > the GUIDs defined in winioctl.h, like GUID_DEVINTERFACE_DISK. To prevent > multiple definition errors, the Microsoft header files using the selectany > attribute. > > I don't know why Microsoft engineered such a complicated solution for > defining GUIDs, but they did, and I would think we should try to make our > header files compatible with it. If it just takes a few preprocessor if > statements that check the GCC version, that seems OK. > > --David > -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [PATCH] guiddef.h: Use __declspec(selectany) on GUID declarations.
> > > It sounds like guiddef.h should probably check the GCC major version. > > Based on the tests people have reported in this thread, I would guess > that > > for GCC 6 and above the selectany attribute on the declaration is > required, > > while on GCC 5 and below the selectany attribute on the declaration is > > forbidden. Or we could get fancy and add a test to the configure script > to > > figure out which is the case. > Both require citation from GCC documentation. But neither is an optimal > solution IMHO. I suggest we ensure each GUID is defined only once then > remove that attribute completely. > When you say "optimal", what are you optimizing for? I'm trying to optimize for being able to port code from Visual Studio to mingw-w64. Microsoft has example code (UsbView) that has a header file that includes the windows.h, followed by initguid.h, followed by winioctl.h. You can see the header file here: https://github.com/Microsoft/Windows-driver-samples/blob/master/usb/usbview/uvcview.h The UsbView code uses that header file in several different translation units, so you end up having a bunch of duplicate GUID definitions for all the GUIDs defined in winioctl.h, like GUID_DEVINTERFACE_DISK. To prevent multiple definition errors, the Microsoft header files using the selectany attribute. I don't know why Microsoft engineered such a complicated solution for defining GUIDs, but they did, and I would think we should try to make our header files compatible with it. If it just takes a few preprocessor if statements that check the GCC version, that seems OK. --David -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [PATCH] guiddef.h: Use __declspec(selectany) on GUID declarations.
I won't be offended if you revert it. I'm not sure what your shell commands do, but as long as there is one GUID defined in one header file, and the selectany attribute is not used properly, you can get multiple definition errors, because that header file could be used in multiple translation units in conjunction with initguid.h. It sounds like guiddef.h should probably check the GCC major version. Based on the tests people have reported in this thread, I would guess that for GCC 6 and above the selectany attribute on the declaration is required, while on GCC 5 and below the selectany attribute on the declaration is forbidden. Or we could get fancy and add a test to the configure script to figure out which is the case. --David Grayson On Tue, May 2, 2017 at 7:49 PM, Liu Hao wrote: > On 2017/5/3 9:33, Liu Hao wrote: > > Kai, should we revert it? We have to deal with the multiple definition > > error thereafter. > > > A number of UUIDs/GUIDs are suffering from such multiple definitions, > which can be discovered using the following commands: > > ```bash > grep -EhrI '^DEFINE_(GUID|OLEGUID)' | >sed -r 's@^DEFINE_(GUID|OLEGUID)\s*\((\w+)\s*,.*$@\2@' | >sort | >tee uuids-all.txt | >uniq > uuids-uniq.txt > diff -U0 uuids-all.txt uuids-uniq.txt | grep -v '^@@' > ``` > > This outputs 106 redundant definitions at the moment. > > -- > Best regards, > LH_Mouse > > > > -- > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > ___ > Mingw-w64-public mailing list > Mingw-w64-public@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/mingw-w64-public > -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Duplicate symbols definition in between uuid.c and extra-uuid.c
Thanks for the info. I used "git blame" on guiddef.h and it looks like the logic has been the same since 2007. I don't see any sign that Kai removed the DECLSPEC_SELECTANY from the GUID declarations, as far as I know it was just always missing. So the code has been the same for 10 years, but then two people have complained about it on the mailing list in the last week. Perhaps there was a change in GCC that made it start ignoring certain attributes on variable definitions if the attributes were not present on the declaration. Tomay: are you able to apply my patch, rebuild your mingw-w64 libraries, and see if it fixes your issue? If you can't do that, could you tell me what the steps are to reproduce your issue so I can see whether the patch helps? Will the patch get merged if I try to reproduce the problem Kai mentioned about having a GUID collision and I fail to reproduce it? --David Grayson On Mon, May 1, 2017 at 6:41 PM, Liu Hao wrote: > On 2017/5/2 3:08, David Grayson wrote: > > Oops, I should have learned my lesson. Well, here it is again. I think > my > > original email 6 days ago was good though. > I did see the patch and we had a discussion on irc. That attribute > seemed to have been removed for a reason, which otherwise caused errors. > > ```plaintext > [23:04:42] jacek ping > [23:07:02] do you recall why we removed that selectany from > GUID definitions? I remember we did together some time ago, but I can't > recall it right > [23:08:33] as we have a suggestion in ML thread > "[Mingw-w64-public] [PATCH] guiddef.h: Use __declspec(selectany) on GUID > declarations."" about adding it > [23:22:17] try `git blame` ? > [23:22:30] maybe you can find the commit that removed it. > [23:24:43] AFAIR this happened already on svn ... in general I > have to admit that annotation of declspec(selectany) is the right thing, > but we had some reason for not doing it. > [23:25:31] scenario I could think about is, that op code > defines its own guids without selectany, which would then collide with > that one with selectany > ``` > > -- > Best regards, > LH_Mouse > > > > -- > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > ___ > Mingw-w64-public mailing list > Mingw-w64-public@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/mingw-w64-public > -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Duplicate symbols definition in between uuid.c and extra-uuid.c
Oops, I should have learned my lesson. Well, here it is again. I think my original email 6 days ago was good though. --David On Mon, May 1, 2017 at 11:47 AM, Ruben Van Boxem wrote: > Your attachment was eaten by the Sourceforge cookie monster :) > > > > 2017-05-01 18:55 GMT+02:00 David Grayson : > > > I sent a patch to this list 6 days ago that fixes a problem with the way > we > > use the selectany attribute. If you're getting multiple definition > errors > > for GUIDs, this will probably fix it. I'll attach it again. > > > > --David > > > > On Mon, May 1, 2017 at 9:34 AM, Mateusz Mikuła > wrote: > > > > > Symbols in libuuid.a are definitely duplicated, tested on MSYS2, > Ubuntu, > > > Arch: > > > > > > nm '/usr/x86_64-w64-mingw32/lib/libuuid.a' | grep FileProtocol > > > R CLSID_FileProtocol > > > r .rdata$CLSID_FileProtocol > > > 00f0 R CLSID_FileProtocol > > > > > > Here is disassembly of first duplicated symbol from Ubuntu: > > > https://paste.ubuntu.com/24493619/ > > > > > > > > > 2017-05-01 18:03 GMT+02:00 Liu Hao : > > > > > > > On 2017/5/1 21:27, Tomay wrote: > > > > > The following UUIDs are defined in both *uuid.c* and *extra-uuid.c* > > > > source > > > > > files, whitch leads to linking errors with duplicate symbols when > > using > > > > > *libuuid.a* > > > > > > > > > In my opinion it is practically incorrect, but you shouldn't get > linker > > > > errors because the macro `INITGUID` is defined in both files hence > each > > > > GUID definition is marked with the `selectany` attribute (see > > definition > > > > of the macro `DEFINE_GUID` in [guiddef.h]). > > > > > > > > -- > > > > Best regards, > > > > LH_Mouse > > > > > > > > > > > > > > > > -- > > > > Check out the vibrant tech community on one of the world's most > > > > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > > > > ___ > > > > Mingw-w64-public mailing list > > > > Mingw-w64-public@lists.sourceforge.net > > > > https://lists.sourceforge.net/lists/listinfo/mingw-w64-public > > > > > > > > > > -- > > > Check out the vibrant tech community on one of the world's most > > > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > > > ___ > > > Mingw-w64-public mailing list > > > Mingw-w64-public@lists.sourceforge.net > > > https://lists.sourceforge.net/lists/listinfo/mingw-w64-public > > > > > > > > > -- > > Check out the vibrant tech community on one of the world's most > > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > > ___ > > Mingw-w64-public mailing list > > Mingw-w64-public@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/mingw-w64-public > > > > > > -- > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > ___ > Mingw-w64-public mailing list > Mingw-w64-public@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/mingw-w64-public > From 7ce782720ce2190442bd835518ebc63e246b0050 Mon Sep 17 00:00:00 2001 From: David Grayson Date: Tue, 25 Apr 2017 07:41:45 -0700 Subject: [PATCH] guiddef.h: Use __declspec(selectany) on GUID declarations. If __declspec(selectany) is not used on the prototype but later used on a definition, GCC seems to ignore it, and you can get multiple-definition errors at link time. That situation can arise in code like Microsoft's usbview utility that has multiple translation units including the following headers in this order: windows.h, initguid.h, winioctl.h. --- mingw-w64-headers/include/guiddef.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/mingw-w64-headers/include/guiddef.h b/mingw-w64-headers/include/guiddef.h index 8d0af1ed..6c9444cf 100644 --- a/mingw-w64-hea
Re: [Mingw-w64-public] Duplicate symbols definition in between uuid.c and extra-uuid.c
I sent a patch to this list 6 days ago that fixes a problem with the way we use the selectany attribute. If you're getting multiple definition errors for GUIDs, this will probably fix it. I'll attach it again. --David On Mon, May 1, 2017 at 9:34 AM, Mateusz Mikuła wrote: > Symbols in libuuid.a are definitely duplicated, tested on MSYS2, Ubuntu, > Arch: > > nm '/usr/x86_64-w64-mingw32/lib/libuuid.a' | grep FileProtocol > R CLSID_FileProtocol > r .rdata$CLSID_FileProtocol > 00f0 R CLSID_FileProtocol > > Here is disassembly of first duplicated symbol from Ubuntu: > https://paste.ubuntu.com/24493619/ > > > 2017-05-01 18:03 GMT+02:00 Liu Hao : > > > On 2017/5/1 21:27, Tomay wrote: > > > The following UUIDs are defined in both *uuid.c* and *extra-uuid.c* > > source > > > files, whitch leads to linking errors with duplicate symbols when using > > > *libuuid.a* > > > > > In my opinion it is practically incorrect, but you shouldn't get linker > > errors because the macro `INITGUID` is defined in both files hence each > > GUID definition is marked with the `selectany` attribute (see definition > > of the macro `DEFINE_GUID` in [guiddef.h]). > > > > -- > > Best regards, > > LH_Mouse > > > > > > > > -- > > Check out the vibrant tech community on one of the world's most > > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > > ___ > > Mingw-w64-public mailing list > > Mingw-w64-public@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/mingw-w64-public > > > > -- > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > ___ > Mingw-w64-public mailing list > Mingw-w64-public@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/mingw-w64-public > -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
[Mingw-w64-public] [PATCH] guiddef.h: Use __declspec(selectany) on GUID declarations.
If __declspec(selectany) is not used on the prototype but later used on
a definition, GCC seems to ignore it, and you can get
multiple-definition errors at link time.
That situation can arise in code like Microsoft's usbview utility that
has multiple translation units including the following headers:
#include
#include
#include
When I have two files that include those header files in that order and
I try to compile them with "i686-w64-mingw32-gcc main.c other.c -o
test.exe", I get a bunch of errors like this:
/home/david/tmp/ccB3GiUW.o:other.c:(.rdata+0x0): multiple definition of
`GUID_DEVINTERFACE_DISK'
/home/david/tmp/ccRH9Bjf.o:main.c:(.rdata+0x0): first defined here
/home/david/tmp/ccB3GiUW.o:other.c:(.rdata+0x10): multiple definition of
`GUID_DEVINTERFACE_CDROM'
/home/david/tmp/ccRH9Bjf.o:main.c:(.rdata+0x10): first defined here
This patch fixes that by adding __declspec(selectany) to the GUID
declarations.
Thanks!
--David Grayson
From 7ce782720ce2190442bd835518ebc63e246b0050 Mon Sep 17 00:00:00 2001
From: David Grayson
Date: Tue, 25 Apr 2017 07:41:45 -0700
Subject: [PATCH] guiddef.h: Use __declspec(selectany) on GUID declarations.
If __declspec(selectany) is not used on the prototype but later used
on a definition, GCC seems to ignore it, and you can get
multiple-definition errors at link time.
That situation can arise in code like Microsoft's usbview utility that
has multiple translation units including the following headers in this
order: windows.h, initguid.h, winioctl.h.
---
mingw-w64-headers/include/guiddef.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/mingw-w64-headers/include/guiddef.h
b/mingw-w64-headers/include/guiddef.h
index 8d0af1ed..6c9444cf 100644
--- a/mingw-w64-headers/include/guiddef.h
+++ b/mingw-w64-headers/include/guiddef.h
@@ -55,13 +55,13 @@ __extension__ template const GUID
&__mingw_uuidof();
#ifdef __cplusplus
#define DEFINE_GUID(name,l,w1,w2,b1,b2,b3,b4,b5,b6,b7,b8) EXTERN_C const GUID
DECLSPEC_SELECTANY name = { l, w1, w2, { b1, b2, b3, b4, b5, b6, b7, b8 } }
#else
#define DEFINE_GUID(name,l,w1,w2,b1,b2,b3,b4,b5,b6,b7,b8) const GUID
DECLSPEC_SELECTANY name = { l, w1, w2, { b1, b2, b3, b4, b5, b6, b7, b8 } }
#endif
#else
-#define DEFINE_GUID(name,l,w1,w2,b1,b2,b3,b4,b5,b6,b7,b8) EXTERN_C const GUID
name
+#define DEFINE_GUID(name,l,w1,w2,b1,b2,b3,b4,b5,b6,b7,b8) EXTERN_C const GUID
DECLSPEC_SELECTANY name
#endif
#define DEFINE_OLEGUID(name, l, w1, w2) DEFINE_GUID (name, l, w1, w2, 0xc0, 0,
0, 0, 0, 0, 0, 0x46)
#ifndef _GUIDDEF_H_
#define _GUIDDEF_H_
--
2.12.1
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
[Mingw-w64-public] [PATCH] usbspec.h: Add some missing structs and definitions.
Hello. The attached patch adds some definitions and structs that were
missing from usbspec.h. I needed this to build the latest version of
Microsoft's usbview program (
https://github.com/DavidEGrayson/nixcrpkgs/tree/master/pkgs/usbview ).
Thanks!
--David Grayson
From 029639a7e7dfa21160ea3f361e41585443c68912 Mon Sep 17 00:00:00 2001
From: David Grayson
Date: Mon, 17 Apr 2017 09:43:39 -0700
Subject: [PATCH] usbspec: Add some missing structs and definitions.
---
mingw-w64-headers/include/usbspec.h | 55 +
1 file changed, 55 insertions(+)
diff --git a/mingw-w64-headers/include/usbspec.h
b/mingw-w64-headers/include/usbspec.h
index 86557d8d..97ab5f3b 100644
--- a/mingw-w64-headers/include/usbspec.h
+++ b/mingw-w64-headers/include/usbspec.h
@@ -213,6 +213,13 @@ typedef struct _USB_BOS_DESCRIPTOR {
#define USB_DEVICE_CAPABILITY_USB20_EXTENSION 0x02
#define USB_DEVICE_CAPABILITY_SUPERSPEED_USB 0x03
#define USB_DEVICE_CAPABILITY_CONTAINER_ID 0x04
+#define USB_DEVICE_CAPABILITY_PLATFORM 0x05
+#define USB_DEVICE_CAPABILITY_POWER_DELIVERY 0x06
+#define USB_DEVICE_CAPABILITY_BATTERY_INFO 0x07
+#define USB_DEVICE_CAPABILITY_PD_CONSUMER_PORT 0x08
+#define USB_DEVICE_CAPABILITY_PD_PROVIDER_PORT 0x09
+#define USB_DEVICE_CAPABILITY_SUPERSPEEDPLUS_USB 0x0A
+#define USB_DEVICE_CAPABILITY_PRECISION_TIME_MEASUREMENT 0x0B
#define USB_DEVICE_CAPABILITY_BILLBOARD 0x0D
typedef struct _USB_DEVICE_CAPABILITY_USB20_EXTENSION_DESCRIPTOR {
@@ -666,6 +673,54 @@ typedef struct
_USB_SUPERSPEEDPLUS_ISOCH_ENDPOINT_COMPANION_DESCRIPTOR {
ULONG dwBytesPerInterval;
}
USB_SUPERSPEEDPLUS_ISOCH_ENDPOINT_COMPANION_DESCRIPTOR,*PUSB_SUPERSPEEDPLUS_ISOCH_ENDPOINT_COMPANION_DESCRIPTOR;
+typedef union _USB_DEVICE_CAPABILITY_SUPERSPEEDPLUS_SPEED {
+ ULONG AsUlong32;
+ struct {
+ULONG SublinkSpeedAttrID:4;
+ULONG LaneSpeedExponent:2;
+ULONG SublinkTypeMode:1;
+ULONG SublinkTypeDir:1;
+ULONG Reserved:6;
+ULONG LinkProtocol:2;
+ULONG LaneSpeedMantissa:16;
+ };
+} USB_DEVICE_CAPABILITY_SUPERSPEEDPLUS_SPEED,
*PUSB_DEVICE_CAPABILITY_SUPERSPEEDPLUS_SPEED;
+
+typedef struct _USB_DEVICE_CAPABILITY_SUPERSPEEDPLUS_USB_DESCRIPTOR {
+ UCHAR bLength;
+ UCHAR bDescriptorType;
+ UCHAR bDevCapabilityType;
+ UCHAR bReserved;
+ union {
+ULONG AsUlong;
+struct {
+ ULONG SublinkSpeedAttrCount:5;
+ ULONG SublinkSpeedIDCount:4;
+ ULONG Reserved:23;
+};
+ } bmAttributes;
+ union {
+USHORT AsUshort;
+struct {
+ USHORT SublinkSpeedAttrID:4;
+ USHORT Reserved:4;
+ USHORT MinRxLaneCount:4;
+ USHORT MinTxLaneCount:4;
+};
+ } wFunctionalitySupport;
+ USHORT wReserved;
+ USB_DEVICE_CAPABILITY_SUPERSPEEDPLUS_SPEED bmSublinkSpeedAttr[1];
+}
USB_DEVICE_CAPABILITY_SUPERSPEEDPLUS_USB_DESCRIPTOR,*PUSB_DEVICE_CAPABILITY_SUPERSPEEDPLUS_USB_DESCRIPTOR;
+
+typedef struct _USB_DEVICE_CAPABILITY_PLATFORM_DESCRIPTOR {
+ UCHAR bLength;
+ UCHAR bDescriptorType;
+ UCHAR bDevCapabilityType;
+ UCHAR bReserved;
+ GUID PlatformCapabilityUuid;
+ UCHAR CapabililityData[1];
+}
USB_DEVICE_CAPABILITY_PLATFORM_DESCRIPTOR,*PUSB_DEVICE_CAPABILITY_PLATFORM_DESCRIPTOR;
+
#include
#endif
--
2.12.1
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [PATCH] stralign: cast ua_wcschr and ua_wcsrchr returns to wchar_t *
I did read the top two answers in the link that Norbert posted:
http://stackoverflow.com/questions/11373203/accessing-inactive-union-member-and-undefined-behavior
The first answer (from ecatmur) indicates that this kind of conversion with
a union would be undefined behavior in C++, but not C. I'm not sure what
else to read, except the latest C++ standard, which was quoted heavily in
the answer.
The second answer (from Bo Persson) provides a useful link to the GCC
documentation which makes me think that GCC provides additional guarantees
beyond what the standard says, and so this kind of conversion would
actually be safe, in both C and C++. Since GCC behaves that way, clang
probably would too. So yeah, the union conversion is probably fine because
of the design of the compilers we care about.
I think casting would work too. When LH_Mouse's reasoned about why the
warnings would not be a problem, Kai said: "Each compiler has its own
variants for this. But well, why we should rely on such things." Are you
more OK with relying on the details of compiler behavior for union
conversions than the details of compiler behavior for warnings?
--David
On Fri, Apr 7, 2017 at 9:31 AM, Kai Tietz wrote:
> 2017-04-07 17:21 GMT+02:00 David Grayson :
> >> type1 *foo(const type1 *my_const_ptr)
> >> {
> >> union {
> >> type1 *t1;
> >> const type1 *ct1;
> >> } v;
> >> v.ct1 = my_const_ptr;
> >> return v.t1;
> >> }
> >
> > Yes, that is sad, and it seems like just a matter of time before a C++
> > compiler looks at the code above and reasons that the write to ct1 can be
> > optimized away because there is no code that ever reads from ct1. Thus
> the
> > read from t1 will be recognized as undefined behavior (probably called a
> > poison value in LLVM) and anything could happen.
>
> LOL ... if a compiler modifies a technical valid language construct,
> and produces by this optimization something it needs to warn about,
> then the compiler has a bug. And well, you should be sad to use such
> a compiler, as it is broken in many aspects.
>
>
> > What was the problem with Mateusz's patch? I think people are implying
> it
> > results in compiler warnings, but I thought casting a pointer to a
> pointer
> > usually doesn't give any warnings.
>
> The problem is that you seems to see an UB, where actually none is.
> Please try read a bit about C++, compatibility to C, and what, and how
> a union on pointer types are treated in a union (especially the part
> about integer scalars & pointers).
>
> ~Kai
>
> PS: As you already recognized, yes the issue is to avoid warnings OP
> doesn't expect them.
>
>
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> Mingw-w64-public mailing list
> Mingw-w64-public@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [PATCH] stralign: cast ua_wcschr and ua_wcsrchr returns to wchar_t *
Oh, it would be a warning with -Wcast-qual, ok, got it. --David
On Fri, Apr 7, 2017 at 8:21 AM, David Grayson
wrote:
> > type1 *foo(const type1 *my_const_ptr)
> > {
> > union {
> > type1 *t1;
> > const type1 *ct1;
> > } v;
> > v.ct1 = my_const_ptr;
> > return v.t1;
> > }
>
> Yes, that is sad, and it seems like just a matter of time before a C++
> compiler looks at the code above and reasons that the write to ct1 can be
> optimized away because there is no code that ever reads from ct1. Thus the
> read from t1 will be recognized as undefined behavior (probably called a
> poison value in LLVM) and anything could happen.
>
> What was the problem with Mateusz's patch? I think people are implying it
> results in compiler warnings, but I thought casting a pointer to a pointer
> usually doesn't give any warnings.
>
> --David
>
> On Fri, Apr 7, 2017 at 4:33 AM, Norbert Pfeiler <
> norbert.pfeiler+mingw-...@gmail.com> wrote:
>
>> That’s a kinda sad stance for a compiler support project, don’t you think?
>>
>> Best, Norbert.
>>
>> Liu Hao schrieb am Fr., 7. Apr. 2017 um 05:48 Uhr:
>>
>> > On 2017/4/7 8:11, Norbert Pfeiler wrote:
>> > > Wasn’t LH_Mouse’s point that even if the warning is explicitly turned
>> on
>> > it
>> > > wouldn’t be shown to the user?
>> > >
>> > > The situation for unions is different in C and C++: (I don’t think
>> that
>> > > it’s just about constness changes anything)
>> > > http://stackoverflow.com/questions/11373203
>> > Nice link. Nevertheless, I don't think most people care about UB unless
>> > UB bites them (that is, unless UB refuses to work silently). XD
>> >
>> > --
>> > Best regards,
>> > LH_Mouse
>> >
>> >
>> >
>> >
>> --
>> > Check out the vibrant tech community on one of the world's most
>> > engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> > ___
>> > Mingw-w64-public mailing list
>> > Mingw-w64-public@lists.sourceforge.net
>> > https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
>> >
>>
>> --
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> ___
>> Mingw-w64-public mailing list
>> Mingw-w64-public@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
>>
>
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [PATCH] stralign: cast ua_wcschr and ua_wcsrchr returns to wchar_t *
> type1 *foo(const type1 *my_const_ptr)
> {
> union {
> type1 *t1;
> const type1 *ct1;
> } v;
> v.ct1 = my_const_ptr;
> return v.t1;
> }
Yes, that is sad, and it seems like just a matter of time before a C++
compiler looks at the code above and reasons that the write to ct1 can be
optimized away because there is no code that ever reads from ct1. Thus the
read from t1 will be recognized as undefined behavior (probably called a
poison value in LLVM) and anything could happen.
What was the problem with Mateusz's patch? I think people are implying it
results in compiler warnings, but I thought casting a pointer to a pointer
usually doesn't give any warnings.
--David
On Fri, Apr 7, 2017 at 4:33 AM, Norbert Pfeiler <
norbert.pfeiler+mingw-...@gmail.com> wrote:
> That’s a kinda sad stance for a compiler support project, don’t you think?
>
> Best, Norbert.
>
> Liu Hao schrieb am Fr., 7. Apr. 2017 um 05:48 Uhr:
>
> > On 2017/4/7 8:11, Norbert Pfeiler wrote:
> > > Wasn’t LH_Mouse’s point that even if the warning is explicitly turned
> on
> > it
> > > wouldn’t be shown to the user?
> > >
> > > The situation for unions is different in C and C++: (I don’t think that
> > > it’s just about constness changes anything)
> > > http://stackoverflow.com/questions/11373203
> > Nice link. Nevertheless, I don't think most people care about UB unless
> > UB bites them (that is, unless UB refuses to work silently). XD
> >
> > --
> > Best regards,
> > LH_Mouse
> >
> >
> >
> >
> --
> > Check out the vibrant tech community on one of the world's most
> > engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> > ___
> > Mingw-w64-public mailing list
> > Mingw-w64-public@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
> >
>
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> Mingw-w64-public mailing list
> Mingw-w64-public@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [PATCH] strsafe.h: Change __inline to __CRT_INLINE
On Mon, Apr 3, 2017 at 10:02 AM, Liu Hao wrote: > On 2017/4/4 0:48, David Grayson wrote: > > I'm a bit confused about the different inlining keywords. From the GCC > > documentation for inlining in the C language ( > > https://gcc.gnu.org/onlinedocs/gcc/Inline.html ) it seemed like "extern > > inline" (i.e. __CRT_INLINE) would be the best thing to use, but I could > not > > find any cases where __inline (which I think is a macro) is worse. > > LH_Mouse's patch does not change what kind of inlining keywords are used, > > it just changes the logic for when to use those keywords. > If you have multiple `extern inline` definitions in different > translation units (TU), a C++ compiler is smart enough to mark them as > 'link once', so the linker will only pick the first definition it finds > and discard the rest. This isn't the case in C. If you have an `extern > inline` function _defined_ in a header, the definition would end up in > every TU that refers that header, resulting in multiple definitions of > that function. What you say matches what I got from my experiments, but it's odd that it doesn't match the GCC documentation I linked to, which says: If you specify both inline and extern in the function definition, then the definition is used only for inlining. In no case is the function compiled on its own, not even if you refer to its address explicitly. Such an address becomes an external reference, as if you had only declared the function, and had not defined it. So it's saying that the TUs might have references to an external function but they will not contain globally-visible definitions that could cause a multiple definition error. There must be something I am missing, but it's OK. --David -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [PATCH] strsafe.h: Change __inline to __CRT_INLINE
I looked into it a little more. __NO_INLINE__ is a macro provided by GCC that is documented to be defined if "no functions will be inlined into their callers". This seems to be defined by GCC by default, but it is not defined when you provide the "-O2" option. __CRT__NO_INLINE is defined in mingw-w64-headers/crt/_mingw.h.in if __NO_INLINE__ is defined (with an exception for Cygwin for some reason). So the reasoning seems to be that we want our header files to have inline definitions if GCC will actually perform inlining, and otherwise we want to use the library versions. I'm not sure why this is done, but it might make unoptimized programs smaller and faster to compile. __STRSAFE__NO_INLINE is defined at the beginning of strsafe.h and says whether the header file is going to have function definitions or not. We want to have strsafe function definitions if GCC will perform inlining *or* we are compiling the mingwex library. So we *don't* want to have strsafe function definitions if GCC will *not* perform inlining *and* we are *not* compiling the mingwex library. The logic for __STRSAFE__NO_INLINE in the header file is correct, but the name of that macro is confusing. STRSAFEAPI, STRSAFEAPIV, and STRSAFE_INLINE_API are macros used for function declarations and definitions in strsafe.h. It seems to me that we should inline in STRSAFEAPI* if GCC will inline and we are not compiling the mingwex library. That's exactly what LH_Mouse's second patch does. I'm a bit confused about the different inlining keywords. From the GCC documentation for inlining in the C language ( https://gcc.gnu.org/onlinedocs/gcc/Inline.html ) it seemed like "extern inline" (i.e. __CRT_INLINE) would be the best thing to use, but I could not find any cases where __inline (which I think is a macro) is worse. LH_Mouse's patch does not change what kind of inlining keywords are used, it just changes the logic for when to use those keywords. Anyway, I tested LH_Mouse's second patch and it works for me, so I'd say it's mergeable. --David On Mon, Apr 3, 2017 at 12:37 AM, Liu Hao wrote: > 1. Neither is defined. This is the case for our users. All functions are > declared as inline and inline definitions are provided. So it is OK. > 2. `__STRSAFE__NO_INLINE` is defined while `__CRT_STRSAFE_IMPL` is not. > This is the case for your problem. All functions are declared inline but > inline definitions are not provided, resulting in warnings about 'inline > functions declared but never defined'. > > 3. `__CRT_STRSAFE_IMPL` is defined. Inline definitions are provided for > calls to external functions. The functions must not be declared as inline > in this case. That is why my previous patch failed. Apologies for that. > > New patch attached. > > > -- > Best regards, > LH_Mouse > > > > From f1c12fd9f35525ca3569c3427f953afb10b47588 Mon Sep 17 00:00:00 2001 > From: Liu Hao > Date: Mon, 3 Apr 2017 02:00:15 +0800 > Subject: [PATCH] include/strsafe.h: Fix warning 'inline function declared > but > never defined'. > > Reference: https://sourceforge.net/p/mingw-w64/mailman/message/35763431/ > Signed-off-by: Liu Hao > --- > mingw-w64-headers/include/strsafe.h | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/mingw-w64-headers/include/strsafe.h > b/mingw-w64-headers/include/strsafe.h > index 36c7796c..74f924ab 100644 > --- a/mingw-w64-headers/include/strsafe.h > +++ b/mingw-w64-headers/include/strsafe.h > @@ -81,7 +81,7 @@ typedef __LONG32 HRESULT; > #endif > #endif > > -#ifndef __CRT_STRSAFE_IMPL > +#if !defined(__CRT__NO_INLINE) && !defined(__CRT_STRSAFE_IMPL) > #define STRSAFEAPI _STRSAFE_EXTERN_C __inline HRESULT WINAPI > /* Variadic functions can't be __stdcall. */ > #define STRSAFEAPIV _STRSAFE_EXTERN_C __inline HRESULT > @@ -91,7 +91,7 @@ typedef __LONG32 HRESULT; > #define STRSAFEAPIV HRESULT > #endif > > -#ifndef __CRT_STRSAFE_IMPL > +#if !defined(__CRT__NO_INLINE) && !defined(__CRT_STRSAFE_IMPL) > > #define STRSAFE_INLINE_API _STRSAFE_EXTERN_C __CRT_INLINE HRESULT WINAPI > #else > #define STRSAFE_INLINE_API HRESULT WINAPI > -- > 2.12.1 > > > > > -- > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > ___ > Mingw-w64-public mailing list > Mingw-w64-public@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/mingw-w64-public > > -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [PATCH] strsafe.h: Change __inline to __CRT_INLINE
Oops, I did a bad job of testing LH_Mouse's patch because I was trying to judge whether a broken build of a program got worse. It turns out his patch made the build worse, causing undefined reference errors for functions like StringCbLengthA that get defined in strsafe.h when compiled as a part of a library. It seems like GCC won't emit a symbol for a function if you declared it as inline (which is not surprising). This is probably because of the issue I pointed out in the second paragraph of my last email. So I'm back to recommending just two options: merge my patch in or look into it more and figure out what the right logic really is. --David On Sun, Apr 2, 2017 at 8:12 PM, David Grayson wrote: > I just tested LH_Mouse's patch and it seems to work fine, so I am OK with > using it instead of mine. > > However, that patch seems like it could be wrong too, since when strsafe.h > is used to compile the library, all the library functions will have > __inline in their declarations even though we are compiling them with the > intent to make normal non-inline functions in a static library. > > Looking back at the original header, there are things that confuse me. > The __STRSAFE_NO_INLINE macro should probably be renamed to > __STRSAFE_NO_IMPL, because the main thing it does is to control whether the > header file provides definitions of its functions or not. The case I > described above is a case where you want function definitions but you don't > want __inline, so the naming of __STRSAFE_NO_INLINE is confusing. > > It also seems like the function prototypes should not depend on > __CRT_STRSAFE_IMPL (as they do currently) or on __STRSAFE_NO_IMPL (as they > do in LH_Mouse's patch). They should depend on some global option that > says whether the functions are inline functions defined in the header or > whether they come from one of the MinGW libraries (the default). Would > __CRT__NO_INLINE be the global option I'm looking for? > > If someone wants to sort out the logic that would be cool, or just merge > in either my patch or LH_Mouse's, since they both fix a bunch of compiler > warnings. > > --David > > > On Sun, Apr 2, 2017 at 11:12 AM, Liu Hao wrote: > >> I'm afraid it isn't the correct fix. If the compiler says it is declared >> and not defined, then it is declared and not defined. >> >> The inline definitions are provided when `__STRSAFE__NO_INLINE` is not >> defined (see line 159 and 873), that is, when `__CRT__NO_INLINE` is defined >> and `__CRT_STRSAFE_IMPL` is not defined (see line 15). However, we fail to >> keep the consistency between these declarations and definitions. These >> functions are declared as inline only when `__CRT_STRSAFE_IMPL` is not >> defined. If only `__CRT__NO_INLINE` is defined, these functions would be >> declared as inline while their inline definitions will not be provided. >> Hence the warning. >> >> The proper way to fix this problem is checking the same condition on >> lines 84, 94 and lines 159, 175, 873, etc. I have attached a new patch for >> this issue. Please test. >> >> -- >> Best regards, >> LH_Mouse >> >> >> >> >> >> From f2f652c023ad1320f69bd7d5f0d5c47376056869 <(737)%20605-6869> Mon Sep >> 17 00:00:00 2001 >> From: Liu Hao >> Date: Mon, 3 Apr 2017 02:00:15 +0800 >> Subject: [PATCH] include/strsafe.h: Fix warning 'inline function declared >> but >> never defined'. >> >> Reference: https://sourceforge.net/p/mingw-w64/mailman/message/35763431/ >> Signed-off-by: Liu Hao >> --- >> mingw-w64-headers/include/strsafe.h | 4 ++-- >> 1 file changed, 2 insertions(+), 2 deletions(-) >> >> diff --git a/mingw-w64-headers/include/strsafe.h >> b/mingw-w64-headers/include/strsafe.h >> index 36c7796c..66b5336f 100644 >> --- a/mingw-w64-headers/include/strsafe.h >> +++ b/mingw-w64-headers/include/strsafe.h >> @@ -81,7 +81,7 @@ typedef __LONG32 HRESULT; >> #endif >> #endif >> >> -#ifndef __CRT_STRSAFE_IMPL >> +#ifndef __STRSAFE__NO_INLINE >> #define STRSAFEAPI _STRSAFE_EXTERN_C __inline HRESULT WINAPI >> /* Variadic functions can't be __stdcall. */ >> #define STRSAFEAPIV _STRSAFE_EXTERN_C __inline HRESULT >> @@ -91,7 +91,7 @@ typedef __LONG32 HRESULT; >> #define STRSAFEAPIV HRESULT >> #endif >> >> -#ifndef __CRT_STRSAFE_IMPL >> +#ifndef __STRSAFE__NO_INLINE >> #define STRSAFE_INLINE_API _STRSAFE_EXTERN_C __CRT_INLINE HRESULT WINAPI >> #else >> #define STRSAFE_INLINE_API HRESULT WINAPI >> -- >> 2.12.1 >> >> &
Re: [Mingw-w64-public] [PATCH] strsafe.h: Change __inline to __CRT_INLINE
I just tested LH_Mouse's patch and it seems to work fine, so I am OK with using it instead of mine. However, that patch seems like it could be wrong too, since when strsafe.h is used to compile the library, all the library functions will have __inline in their declarations even though we are compiling them with the intent to make normal non-inline functions in a static library. Looking back at the original header, there are things that confuse me. The __STRSAFE_NO_INLINE macro should probably be renamed to __STRSAFE_NO_IMPL, because the main thing it does is to control whether the header file provides definitions of its functions or not. The case I described above is a case where you want function definitions but you don't want __inline, so the naming of __STRSAFE_NO_INLINE is confusing. It also seems like the function prototypes should not depend on __CRT_STRSAFE_IMPL (as they do currently) or on __STRSAFE_NO_IMPL (as they do in LH_Mouse's patch). They should depend on some global option that says whether the functions are inline functions defined in the header or whether they come from one of the MinGW libraries (the default). Would __CRT__NO_INLINE be the global option I'm looking for? If someone wants to sort out the logic that would be cool, or just merge in either my patch or LH_Mouse's, since they both fix a bunch of compiler warnings. --David On Sun, Apr 2, 2017 at 11:12 AM, Liu Hao wrote: > > I'm afraid it isn't the correct fix. If the compiler says it is declared > and not defined, then it is declared and not defined. > > The inline definitions are provided when `__STRSAFE__NO_INLINE` is not > defined (see line 159 and 873), that is, when `__CRT__NO_INLINE` is defined > and `__CRT_STRSAFE_IMPL` is not defined (see line 15). However, we fail to > keep the consistency between these declarations and definitions. These > functions are declared as inline only when `__CRT_STRSAFE_IMPL` is not > defined. If only `__CRT__NO_INLINE` is defined, these functions would be > declared as inline while their inline definitions will not be provided. > Hence the warning. > > The proper way to fix this problem is checking the same condition on lines > 84, 94 and lines 159, 175, 873, etc. I have attached a new patch for this > issue. Please test. > > -- > Best regards, > LH_Mouse > > > > > > From f2f652c023ad1320f69bd7d5f0d5c47376056869 <(737)%20605-6869> Mon Sep > 17 00:00:00 2001 > From: Liu Hao > Date: Mon, 3 Apr 2017 02:00:15 +0800 > Subject: [PATCH] include/strsafe.h: Fix warning 'inline function declared > but > never defined'. > > Reference: https://sourceforge.net/p/mingw-w64/mailman/message/35763431/ > Signed-off-by: Liu Hao > --- > mingw-w64-headers/include/strsafe.h | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/mingw-w64-headers/include/strsafe.h > b/mingw-w64-headers/include/strsafe.h > index 36c7796c..66b5336f 100644 > --- a/mingw-w64-headers/include/strsafe.h > +++ b/mingw-w64-headers/include/strsafe.h > @@ -81,7 +81,7 @@ typedef __LONG32 HRESULT; > #endif > #endif > > -#ifndef __CRT_STRSAFE_IMPL > +#ifndef __STRSAFE__NO_INLINE > #define STRSAFEAPI _STRSAFE_EXTERN_C __inline HRESULT WINAPI > /* Variadic functions can't be __stdcall. */ > #define STRSAFEAPIV _STRSAFE_EXTERN_C __inline HRESULT > @@ -91,7 +91,7 @@ typedef __LONG32 HRESULT; > #define STRSAFEAPIV HRESULT > #endif > > -#ifndef __CRT_STRSAFE_IMPL > +#ifndef __STRSAFE__NO_INLINE > #define STRSAFE_INLINE_API _STRSAFE_EXTERN_C __CRT_INLINE HRESULT WINAPI > #else > #define STRSAFE_INLINE_API HRESULT WINAPI > -- > 2.12.1 > > > > > -- > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > ___ > Mingw-w64-public mailing list > Mingw-w64-public@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/mingw-w64-public > > -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [PATCH] strsafe.h: Change __inline to __CRT_INLINE
OK, I'm disappointed in gmail then. Here is a version with a .txt extension so it should have the right MIME type and get through. --David On Sun, Apr 2, 2017 at 1:00 AM, Mateusza Mikuła wrote: > Looks like patch couldn't make it through. > > On April 2, 2017 2:55:35 AM GMT+02:00, David Grayson < > davidegray...@gmail.com> wrote: > >In MSYS2 and in my own compilation of a mingw-w64 GCC 6.3.0 toolchain, > >strsafe.h was producing tons of warnings when included because it was > >declaring its functions as inline but then not defining them. > > > >I think the right solution is to change "__inline" to "__CRT_INLINE" so > >I > >have attached a patch for doing that. I could have just removed the > >"__inline" but it seems like mingw-w64 has a feature of making all its > >functions be inline and I was not sure, but probably the right way to > >do > >that is to use __CRT_INLINE. > > > >Thanks! > > > >--David Grayson > > -- > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > ___ > Mingw-w64-public mailing list > Mingw-w64-public@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/mingw-w64-public > From 3ac3340f9ab3d2ad43bd28a0882be8714123e5de Mon Sep 17 00:00:00 2001 From: David Grayson Date: Sat, 1 Apr 2017 17:51:17 -0700 Subject: [PATCH] strsafe.h: Change __inline to __CRT_INLINE This avoids warnings from GCC about inline functions that are not defined. --- mingw-w64-headers/include/strsafe.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/mingw-w64-headers/include/strsafe.h b/mingw-w64-headers/include/strsafe.h index 36c7796c..ba2eb610 100644 --- a/mingw-w64-headers/include/strsafe.h +++ b/mingw-w64-headers/include/strsafe.h @@ -82,9 +82,9 @@ typedef __LONG32 HRESULT; #endif #ifndef __CRT_STRSAFE_IMPL -#define STRSAFEAPI _STRSAFE_EXTERN_C __inline HRESULT WINAPI +#define STRSAFEAPI _STRSAFE_EXTERN_C __CRT_INLINE HRESULT WINAPI /* Variadic functions can't be __stdcall. */ -#define STRSAFEAPIV _STRSAFE_EXTERN_C __inline HRESULT +#define STRSAFEAPIV _STRSAFE_EXTERN_C __CRT_INLINE HRESULT #else #define STRSAFEAPI HRESULT WINAPI /* Variadic functions can't be __stdcall. */ -- 2.12.1 -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
[Mingw-w64-public] [PATCH] strsafe.h: Change __inline to __CRT_INLINE
In MSYS2 and in my own compilation of a mingw-w64 GCC 6.3.0 toolchain, strsafe.h was producing tons of warnings when included because it was declaring its functions as inline but then not defining them. I think the right solution is to change "__inline" to "__CRT_INLINE" so I have attached a patch for doing that. I could have just removed the "__inline" but it seems like mingw-w64 has a feature of making all its functions be inline and I was not sure, but probably the right way to do that is to use __CRT_INLINE. Thanks! --David Grayson -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [PATCH] Use LPCVOID instead of 'const LPVOID' for VerQueryValue
Oops, that was the problem then. It was "application/octet-stream" because I was constructing the email with the Ruby "mail" gem that doesn't recognize ".patch" files as being text. I'll use better methods in the future. --David On Sun, Mar 19, 2017 at 10:13 PM, NightStrike wrote: > Do you know what content type you attached as? We have to explicitly > allow each type. The current list is: > > application/pgp-signature > multipart/mixed > multipart/alternative > multipart/signed > text/plain > text/x-patch > > If the content type is left unspecified, then the attachment is > deleted. I can add anything you like. > > On Sun, Mar 19, 2017 at 10:30 PM, David Grayson > wrote: > > NightStrike, > > > > The mailing list swallowed the patch in the message I sent on March 16th. > > I can see in GMail that I did have a patch attached to my message, but no > > attachment is visible in the archive here: > > > > https://sourceforge.net/p/mingw-w64/mailman/message/35729302/ > > > > --David Grayson > > > > On Sun, Mar 19, 2017 at 7:03 PM, NightStrike > wrote: > > > >> On Mar 16, 2017 1:40 PM, "Liu Hao" wrote: > >> > >> On 2017/3/17 0:51, David Grayson wrote: > >> > I was trying to compile Qt and I ran into an error because Qt is > >> > passing a const pointer to the first argument of VerQueryValue, which > >> > is not properly marked as const in the mingw-w64 header files. This > >> > patch fixes that. > >> Please send the patch both inline and as an attachment, since SF mailing > >> lists swallow attachments frequently. > >> > >> > >> It shouldn't. If it does, tell me and I'll address it. I believe I > already > >> fixed one issue you brought up a while ago. I haven't seen any since. > >> > >> -- > >> Check out the vibrant tech community on one of the world's most > >> engaging tech sites, Slashdot.org! http://sdm.link/slashdot > >> ___ > >> Mingw-w64-public mailing list > >> Mingw-w64-public@lists.sourceforge.net > >> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public > >> > > > -- > > Check out the vibrant tech community on one of the world's most > > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > > ___ > > Mingw-w64-public mailing list > > Mingw-w64-public@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/mingw-w64-public > > > -- > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > ___ > Mingw-w64-public mailing list > Mingw-w64-public@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/mingw-w64-public > -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [PATCH] Use LPCVOID instead of 'const LPVOID' for VerQueryValue
NightStrike, The mailing list swallowed the patch in the message I sent on March 16th. I can see in GMail that I did have a patch attached to my message, but no attachment is visible in the archive here: https://sourceforge.net/p/mingw-w64/mailman/message/35729302/ --David Grayson On Sun, Mar 19, 2017 at 7:03 PM, NightStrike wrote: > On Mar 16, 2017 1:40 PM, "Liu Hao" wrote: > > On 2017/3/17 0:51, David Grayson wrote: > > I was trying to compile Qt and I ran into an error because Qt is > > passing a const pointer to the first argument of VerQueryValue, which > > is not properly marked as const in the mingw-w64 header files. This > > patch fixes that. > Please send the patch both inline and as an attachment, since SF mailing > lists swallow attachments frequently. > > > It shouldn't. If it does, tell me and I'll address it. I believe I already > fixed one issue you brought up a while ago. I haven't seen any since. > > -- > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > ___ > Mingw-w64-public mailing list > Mingw-w64-public@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/mingw-w64-public > -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
[Mingw-w64-public] [PATCH] (again) Use LPCVOID instead of 'const LPVOID' for VerQueryValue.
Hello.
Here is that patch again. Thanks!
--David Grayson
>From 63f1126b246df52e4252d148897f3e262931368b Mon Sep 17 00:00:00 2001
From: David Grayson
Date: Thu, 16 Mar 2017 19:35:23 -0700
Subject: [PATCH] Use LPCVOID instead of 'const LPVOID' for VerQueryValue.
Apparently "const LPVOID" is different from "LPCVOID". You can see
the difference for yourself by trying to compile this small bit of C
code:
#include
void x(const LPVOID);
void y(LPCVOID);
void test() {
const char * data;
x(data);
y(data);
}
---
mingw-w64-headers/include/winver.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/mingw-w64-headers/include/winver.h
b/mingw-w64-headers/include/winver.h
index a905c9fe..065f5c06 100644
--- a/mingw-w64-headers/include/winver.h
+++ b/mingw-w64-headers/include/winver.h
@@ -144,8 +144,8 @@ extern "C" {
WINBOOL WINAPI GetFileVersionInfoW(LPCWSTR lptstrFilename,DWORD
dwHandle,DWORD dwLen,LPVOID lpData);
DWORD WINAPI VerLanguageNameA(DWORD wLang,LPSTR szLang,DWORD nSize);
DWORD WINAPI VerLanguageNameW(DWORD wLang,LPWSTR szLang,DWORD nSize);
- WINBOOL WINAPI VerQueryValueA(const LPVOID pBlock,LPCSTR lpSubBlock,LPVOID
*lplpBuffer,PUINT puLen);
- WINBOOL WINAPI VerQueryValueW(const LPVOID pBlock,LPCWSTR lpSubBlock,LPVOID
*lplpBuffer,PUINT puLen);
+ WINBOOL WINAPI VerQueryValueA(LPCVOID pBlock,LPCSTR lpSubBlock,LPVOID
*lplpBuffer,PUINT puLen);
+ WINBOOL WINAPI VerQueryValueW(LPCVOID pBlock,LPCWSTR lpSubBlock,LPVOID
*lplpBuffer,PUINT puLen);
#endif
#ifdef __cplusplus
--
2.11.1
>From 63f1126b246df52e4252d148897f3e262931368b Mon Sep 17 00:00:00 2001
From: David Grayson
Date: Thu, 16 Mar 2017 19:35:23 -0700
Subject: [PATCH] Use LPCVOID instead of 'const LPVOID' for VerQueryValue.
Apparently "const LPVOID" is different from "LPCVOID". You can see
the difference for yourself by trying to compile this small bit of C
code:
#include
void x(const LPVOID);
void y(LPCVOID);
void test() {
const char * data;
x(data);
y(data);
}
---
mingw-w64-headers/include/winver.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/mingw-w64-headers/include/winver.h
b/mingw-w64-headers/include/winver.h
index a905c9fe..065f5c06 100644
--- a/mingw-w64-headers/include/winver.h
+++ b/mingw-w64-headers/include/winver.h
@@ -144,8 +144,8 @@ extern "C" {
WINBOOL WINAPI GetFileVersionInfoW(LPCWSTR lptstrFilename,DWORD
dwHandle,DWORD dwLen,LPVOID lpData);
DWORD WINAPI VerLanguageNameA(DWORD wLang,LPSTR szLang,DWORD nSize);
DWORD WINAPI VerLanguageNameW(DWORD wLang,LPWSTR szLang,DWORD nSize);
- WINBOOL WINAPI VerQueryValueA(const LPVOID pBlock,LPCSTR lpSubBlock,LPVOID
*lplpBuffer,PUINT puLen);
- WINBOOL WINAPI VerQueryValueW(const LPVOID pBlock,LPCWSTR lpSubBlock,LPVOID
*lplpBuffer,PUINT puLen);
+ WINBOOL WINAPI VerQueryValueA(LPCVOID pBlock,LPCSTR lpSubBlock,LPVOID
*lplpBuffer,PUINT puLen);
+ WINBOOL WINAPI VerQueryValueW(LPCVOID pBlock,LPCWSTR lpSubBlock,LPVOID
*lplpBuffer,PUINT puLen);
#endif
#ifdef __cplusplus
--
2.11.1
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
[Mingw-w64-public] [PATCH] Use LPCVOID instead of 'const LPVOID' for VerQueryValue
I was trying to compile Qt and I ran into an error because Qt is
passing a const pointer to the first argument of VerQueryValue, which
is not properly marked as const in the mingw-w64 header files. This
patch fixes that.
Apparently "const LPVOID" is different from "LPCVOID". You can see
the difference for yourself by trying to compile this small bit of C
code:
#include
void x(const LPVOID);
void y(LPCVOID);
void test() {
const char * data;
x(data);
y(data);
}
Thanks!
--David Grayson
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] LoadImage defined in x86_64-w64-mingw32/include/winuser.h
You can run "grep -ir LoadImage" to figure out what kind of definition for LoadImage is provided by mingw-w64. It looks like include/winuser.h has this line: #define LoadImage __MINGW_NAME_AW(LoadImage) So in your header file for your LoadImage class, you can simply write: #undef LoadImage C does not have namespaces. The Windows API from Microsoft defines functions with very broad names, LoadImage, GetLastError, CreateFile, etc. In order to compile Windows software successfully, mingw-w64 has to provide definitions for Windows API functions like that. I would recommend changing the name of your class. When an experienced Windows programmer sees "LoadImage(...)" in your code they might think you are calling the Windows LoadImage functions but you are actually constructing an instance of your class. --David Grayson On Tue, Mar 14, 2017 at 3:42 AM, Mario Emmenlauer wrote: > > I'm not sure where to ask about this, please redirect me as needed! > > I have a C++ class with a function "LoadImage", which caused a > compile error on Windows. After some digging, I think that a define or > function from winuser.h with a similar name is the culprit. I'm slightly > confused by this, because I naiively assumed that such global defines > would be better obscured. Admittedly I'm quite ignorant as to how this > "hiding" should work, I just assumed that i.e. they would have very > specific names, are encapsulated in namespaces, or live in very specific > headers. > > Is there some way for me not to fall into the same trap with other > functions again? I recall some WIN32_LEAN_AND_MEAN define that was > used in the old days to reduce the bloat coming from windows headers, > when using MSVC. Is this still useful, and/or are there better methods? > > Thanks for and advise! > > All the best, > > Mario Emmenlauer > > > -- > BioDataAnalysis GmbH, Mario Emmenlauer Tel. Buero: +49-89-74677203 > Balanstr. 43 mailto: memmenlauer * biodataanalysis.de > D-81669 München http://www.biodataanalysis.de/ > > -- > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > ___ > Mingw-w64-public mailing list > Mingw-w64-public@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/mingw-w64-public -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [PATCH] intrin-impl.h: Guard all intrins definitions by __has_builtin.
If the compiler has a builtin for the intrinsic, why would mingw-w64 still provide a prototype for it? It seems like it would have no benefit and be likely to just cause compiler errors in the future. --David On Fri, Feb 17, 2017 at 4:25 AM, Jacek Caban wrote: > Please review. > > --- > mingw-w64-headers/include/psdk_inc/intrin-impl.h | 230 > ++- > 1 file changed, 226 insertions(+), 4 deletions(-) > > > > -- > Check out the vibrant tech community on one of the world's most > engaging tech sites, SlashDot.org! http://sdm.link/slashdot > ___ > Mingw-w64-public mailing list > Mingw-w64-public@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/mingw-w64-public > -- Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [PATCH] intrin-impl.h: Added __popcnt16, __popcnt, and __popcnt64.
Ah, from your paste, it looks like mingw-w64 and clang are fighting to declare a lot of builtins when -fms-extensions is turned on. I would personally prefer to use compiler implementations of these things instead of header file implementations, so I think that mingw-w64 should try to support clang with -fms-extensions turned on. I'm not sure it try to support clang when -fms-extensions is turned off. But it would be easy to do so since clang has the __has_builtin macro which can check which builtins are enabled. --David On Wed, Feb 8, 2017 at 4:35 PM, Mateusz Mikuła wrote: > You are right David and now I remember the thing about ms-extensions. > Declspec was part of those extensions and enabling it by default caused > errors with specific code so declspec was changed to general attribute > instead. > Since I have clang git build (trying to upstream some patches used by > MSYS2), I tried it also: > https://paste.ubuntu.com/23957478/ > > While for 3.9.x Clang `-fms-extensions` didn't hurt, master branch require > some corrections but it is another issue. > > > 2017-02-09 0:15 GMT+01:00 David Grayson : > >> I can confirm that MSYS2's x86_64 clang++ compiler does not support >> __popcnt but does support __builtin_popcount. I looked into it a >> little bit, and found out that the clang commit that adds the __popcnt >> builtins is very recent (September 2016). I seems like it has not >> made it into a release yet. >> >> Here is the commit: >> >> https://github.com/llvm-mirror/clang/commit/5eb95c4c284486351e3ed0fdad011a >> cf41540c8b >> >> The source code archive that Alexey used to build the MSYS2 clang++ >> does not have the changes from that commit in it: >> >> http://repo.msys2.org/mingw/sources/mingw-w64-clang-3.9.1-3.src.tar.gz >> >> I don't intend to submit any more patches for this issue. Jacek has >> already committed my patch to mingw-w64 (thanks!). Once the new >> version of clang comes out and people start using it there should not >> be any problems. If any clang users are itching to use __popcnt >> before the new version of clang comes out, they can easily remove the >> #if I put in intrin-impl.h. They could also use __has_builtin in >> intrin-impl.h to detect whether clang has the builtin or not. >> >> Mateusz, the "CodeGen" folder in clang is not just used for MSVC libs, >> it has tons of general-purpose code for generating LLVM code from >> C/C++ code. >> >> --David Grayson >> >> On Wed, Feb 8, 2017 at 1:24 PM, Mateusz wrote: >> > Opps, gmail put output into quote. Improved version: >> > $ clang++ popcnt.cc -std=c++14 -fms-extensions >> > popcnt.cc:9:26: error: use of undeclared identifier '__popcnt16' >> > unsigned short usr = __popcnt16(us[i]); >> > ^ >> > popcnt.cc:17:24: error: use of undeclared identifier '__popcnt' >> > unsigned int uir = __popcnt(ui[i]); >> >^ >> > popcnt.cc:26:28: error: use of undeclared identifier '__popcnt64'; did >> you >> > mean '_popcnt64'? >> > unsigned __int64 ulr = __popcnt64(ul[i]); >> >^~ >> >_popcnt64 >> > D:\msys64\mingw64\bin\..\lib\clang\3.9.1\include\popcntintrin.h:90:1: >> note: >> > '_popcnt64' declared here >> > _popcnt64(long long __A) >> > ^ >> > 3 errors generated. >> > >> > >> > >> > 2017-02-08 22:22 GMT+01:00 Mateusz : >> > >> >> I think ms-extensions was made default option for mingw and msvc clang >> and >> >> codegen is used only for creating msvc libs. Here is Clang output >> anyway: >> >> >> >> $ clang++ popcnt.cc -std=c++14 -fms-extensions >> >> popcnt.cc:9:26: error: use of undeclared identifier '__popcnt16' >> >> unsigned short usr = __popcnt16(us[i]); >> >> ^ >> >> popcnt.cc:17:24: error: use of undeclared identifier '__popcnt' >> >> unsigned int uir = __popcnt(ui[i]); >> >>^ >> >> popcnt.cc:26:28: error: use of undeclared identifier '__popcnt64'; did >> you >> >> mean '_popcnt64'? >> >> unsigned __int64 ulr = __popcnt64(ul[i]); >> >>^~ >> >>_popcnt64 >> >> D:\msys64\mingw64\bin\..\lib\clang\3.9.1\include\popcnt
Re: [Mingw-w64-public] [PATCH] intrin-impl.h: Added __popcnt16, __popcnt, and __popcnt64.
I can confirm that MSYS2's x86_64 clang++ compiler does not support __popcnt but does support __builtin_popcount. I looked into it a little bit, and found out that the clang commit that adds the __popcnt builtins is very recent (September 2016). I seems like it has not made it into a release yet. Here is the commit: https://github.com/llvm-mirror/clang/commit/5eb95c4c284486351e3ed0fdad011acf41540c8b The source code archive that Alexey used to build the MSYS2 clang++ does not have the changes from that commit in it: http://repo.msys2.org/mingw/sources/mingw-w64-clang-3.9.1-3.src.tar.gz I don't intend to submit any more patches for this issue. Jacek has already committed my patch to mingw-w64 (thanks!). Once the new version of clang comes out and people start using it there should not be any problems. If any clang users are itching to use __popcnt before the new version of clang comes out, they can easily remove the #if I put in intrin-impl.h. They could also use __has_builtin in intrin-impl.h to detect whether clang has the builtin or not. Mateusz, the "CodeGen" folder in clang is not just used for MSVC libs, it has tons of general-purpose code for generating LLVM code from C/C++ code. --David Grayson On Wed, Feb 8, 2017 at 1:24 PM, Mateusz wrote: > Opps, gmail put output into quote. Improved version: > $ clang++ popcnt.cc -std=c++14 -fms-extensions > popcnt.cc:9:26: error: use of undeclared identifier '__popcnt16' > unsigned short usr = __popcnt16(us[i]); > ^ > popcnt.cc:17:24: error: use of undeclared identifier '__popcnt' > unsigned int uir = __popcnt(ui[i]); >^ > popcnt.cc:26:28: error: use of undeclared identifier '__popcnt64'; did you > mean '_popcnt64'? > unsigned __int64 ulr = __popcnt64(ul[i]); >^~ >_popcnt64 > D:\msys64\mingw64\bin\..\lib\clang\3.9.1\include\popcntintrin.h:90:1: note: > '_popcnt64' declared here > _popcnt64(long long __A) > ^ > 3 errors generated. > > > > 2017-02-08 22:22 GMT+01:00 Mateusz : > >> I think ms-extensions was made default option for mingw and msvc clang and >> codegen is used only for creating msvc libs. Here is Clang output anyway: >> >> $ clang++ popcnt.cc -std=c++14 -fms-extensions >> popcnt.cc:9:26: error: use of undeclared identifier '__popcnt16' >> unsigned short usr = __popcnt16(us[i]); >> ^ >> popcnt.cc:17:24: error: use of undeclared identifier '__popcnt' >> unsigned int uir = __popcnt(ui[i]); >>^ >> popcnt.cc:26:28: error: use of undeclared identifier '__popcnt64'; did you >> mean '_popcnt64'? >> unsigned __int64 ulr = __popcnt64(ul[i]); >> ^~ >>_popcnt64 >> D:\msys64\mingw64\bin\..\lib\clang\3.9.1\include\popcntintrin.h:90:1: >> note: '_popcnt64' declared here >> _popcnt64(long long __A) >> ^ >> 3 errors generated. >> >> 2017-02-08 20:10 GMT+01:00 David Grayson : >> >>> Mateusz, thanks for looking in to this. >>> >>> Here are the relevant lines from the clang source code that indicate >>> that it supports those builtins: >>> >>> https://github.com/llvm-mirror/clang/blob/3e45634a7f951c2306 >>> e4b368f9fb8c8d80c48273/include/clang/Basic/Builtins.def#L760-L762 >>> https://github.com/llvm-mirror/clang/blob/4cedfcc1ecf8387082 >>> 183508604b7f47c634f708/lib/CodeGen/CGBuiltin.cpp#L804-L821 >>> >>> Can you try your clang test again with the "-fms-extensions" argument? >>> >>> (I tried to test clang myself earlier but I had various issues. I >>> could probably try again tonight if you don't want to.) >>> >>> --David >>> >>> On Wed, Feb 8, 2017 at 10:54 AM, Mateusz wrote: >>> > MSYS2 native Clang test-popcnt.cpp: >>> > >>> > $ clang++ popcnt.cc -std=c++14 >>> > popcnt.cc:9:26: error: use of undeclared identifier '__popcnt16' >>> > unsigned short usr = __popcnt16(us[i]); >>> > ^ >>> > popcnt.cc:17:24: error: use of undeclared identifier '__popcnt' >>> > unsigned int uir = __popcnt(ui[i]); >>> >^ >>> > popcnt.cc:26:28: error: use of undeclared identifier '__popcnt64'; did >>> you >>> > mean '_popcnt64'? >>> > unsigned __int64 ulr = __popcnt64(ul[i]); >
Re: [Mingw-w64-public] [PATCH] intrin-impl.h: Added __popcnt16, __popcnt, and __popcnt64.
Mateusz, thanks for looking in to this. Here are the relevant lines from the clang source code that indicate that it supports those builtins: https://github.com/llvm-mirror/clang/blob/3e45634a7f951c2306e4b368f9fb8c8d80c48273/include/clang/Basic/Builtins.def#L760-L762 https://github.com/llvm-mirror/clang/blob/4cedfcc1ecf8387082183508604b7f47c634f708/lib/CodeGen/CGBuiltin.cpp#L804-L821 Can you try your clang test again with the "-fms-extensions" argument? (I tried to test clang myself earlier but I had various issues. I could probably try again tonight if you don't want to.) --David On Wed, Feb 8, 2017 at 10:54 AM, Mateusz wrote: > MSYS2 native Clang test-popcnt.cpp: > > $ clang++ popcnt.cc -std=c++14 > popcnt.cc:9:26: error: use of undeclared identifier '__popcnt16' > unsigned short usr = __popcnt16(us[i]); > ^ > popcnt.cc:17:24: error: use of undeclared identifier '__popcnt' > unsigned int uir = __popcnt(ui[i]); >^ > popcnt.cc:26:28: error: use of undeclared identifier '__popcnt64'; did you > mean '_popcnt64'? > unsigned __int64 ulr = __popcnt64(ul[i]); >^~ >_popcnt64 > D:\msys64\mingw64\bin\..\lib\clang\3.9.1\include\popcntintrin.h:90:1: note: > '_popcnt64' declared here > _popcnt64(long long __A) > ^ > 3 errors generated. > > Probably its safe to enable it for Clang, I'll try tomorrow late. > > 2017-02-08 18:37 GMT+01:00 David Grayson : > >> Hello. This patch adds support for the Microsoft __popcnt16, __popcnt, >> and __popcnt64 intrinsics, which are documented here: >> >> https://msdn.microsoft.com/en-us/library/bb385231.aspx >> >> I was trying to compile ANGLE recently and one of the first errors I >> encountered was due to both GCC/mingw-w64 not supporting __popcnt. >> >> I attached the simple C++ program I used to test this patch. >> >> I am not totally sure, but it looks like Clang already supports the >> __popcnt intrinsics because I saw code for it in the clang repository. So >> that is why this patch has "#if !defined(__clang__)" around it. >> >> I read the documentation for intrin.h and intrin-impl.h and I believe this >> patch follows all the rules. It would be great if it could be merged in. >> Thanks! >> >> --David Grayson >> >> >> -- >> Check out the vibrant tech community on one of the world's most >> engaging tech sites, SlashDot.org! http://sdm.link/slashdot >> ___ >> Mingw-w64-public mailing list >> Mingw-w64-public@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public >> >> > -- > Check out the vibrant tech community on one of the world's most > engaging tech sites, SlashDot.org! http://sdm.link/slashdot > ___ > Mingw-w64-public mailing list > Mingw-w64-public@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/mingw-w64-public -- Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
[Mingw-w64-public] [PATCH] intrin-impl.h: Added __popcnt16, __popcnt, and __popcnt64.
Hello. This patch adds support for the Microsoft __popcnt16, __popcnt, and
__popcnt64 intrinsics, which are documented here:
https://msdn.microsoft.com/en-us/library/bb385231.aspx
I was trying to compile ANGLE recently and one of the first errors I
encountered was due to both GCC/mingw-w64 not supporting __popcnt.
I attached the simple C++ program I used to test this patch.
I am not totally sure, but it looks like Clang already supports the __popcnt
intrinsics because I saw code for it in the clang repository. So that is why
this patch has "#if !defined(__clang__)" around it.
I read the documentation for intrin.h and intrin-impl.h and I believe this
patch follows all the rules. It would be great if it could be merged in.
Thanks!
--David Grayson
diff --git a/mingw-w64-headers/include/psdk_inc/intrin-impl.h
b/mingw-w64-headers/include/psdk_inc/intrin-impl.h
index f8dc78f..fc781ff 100644
--- a/mingw-w64-headers/include/psdk_inc/intrin-impl.h
+++ b/mingw-w64-headers/include/psdk_inc/intrin-impl.h
@@ -971,6 +971,40 @@ __buildbittesti(InterlockedBitTestAndComplement, __LONG32,
"eor", "M", volatile)
#if defined(__x86_64__) || defined(_AMD64_) || defined(__i386__) ||
defined(_X86_) || defined(__arm__) || defined(_ARM_)
+#if !defined(__clang__)
+
+#if __INTRINSIC_PROLOG(__popcnt16)
+unsigned short __popcnt16(unsigned short);
+__INTRINSICS_USEINLINE
+unsigned short __popcnt16(unsigned short value)
+{
+return __builtin_popcount(value);
+}
+#define __INTRINSIC_DEFINED___popcnt16
+#endif /* __INTRINSIC_PROLOG */
+
+#if __INTRINSIC_PROLOG(__popcnt)
+unsigned int __popcnt(unsigned int);
+__INTRINSICS_USEINLINE
+unsigned int __popcnt(unsigned int value)
+{
+return __builtin_popcount(value);
+}
+#define __INTRINSIC_DEFINED___popcnt
+#endif /* __INTRINSIC_PROLOG */
+
+#if __INTRINSIC_PROLOG(__popcnt64)
+unsigned __int64 __popcnt64(unsigned __int64);
+__INTRINSICS_USEINLINE
+unsigned __int64 __popcnt64(unsigned __int64 value)
+{
+return __builtin_popcountll(value);
+}
+#define __INTRINSIC_DEFINED___popcnt64
+#endif /* __INTRINSIC_PROLOG */
+
+#endif /* !defined(__clang__) */
+
#if __INTRINSIC_PROLOG(_InterlockedAnd)
__LONG32 _InterlockedAnd(__LONG32 volatile *, __LONG32);
__INTRINSICS_USEINLINE
#include
#include
int main()
{
// Test __popcnt16
unsigned short us[3] = {0, 0xFF, 0x};
for (int i = 0; i < 3; i++) {
unsigned short usr = __popcnt16(us[i]);
std::cout << "__popcnt16(0x" << std::hex << us[i] <<
") = " << std::dec << usr << std::endl;
}
// Test __popcnt
unsigned int ui[4] = {0, 0xFF, 0x, 0x};
for (int i = 0; i < 4; i++) {
unsigned int uir = __popcnt(ui[i]);
std::cout << "__popcnt(0x" << std::hex << ui[i] <<
") = " << std::dec << uir << std::endl;
}
// Test __popcnt64
unsigned __int64 ul[5] = {0, 0xFF, 0x, 0x, 0xFF00FF00FF00FF00};
for (int i = 0; i < 5; i++) {
unsigned __int64 ulr = __popcnt64(ul[i]);
std::cout << "__popcnt(0x" << std::hex << ul[i] <<
") = " << std::dec << ulr << std::endl;
}
std::cout << "sizeof(unsigned long) = " << sizeof(unsigned long) << std::endl;
std::cout << "sizeof(unsigned long long) = " << sizeof(unsigned long long) <<
std::endl;
}
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [PATH] math.h: The type of C99 INFINITY and NAN shall be float.
Patch is not attached. --David On Sat, Nov 12, 2016 at 7:33 PM, Nakai Yuta wrote: > C99 defines INFINITY and NAN macros as float. > patch is attached. > > > > -- > Developer Access Program for Intel Xeon Phi Processors > Access to Intel Xeon Phi processor-based developer platforms. > With one year of Intel Parallel Studio XE. > Training and support from Colfax. > Order your platform today. http://sdm.link/xeonphi > ___ > Mingw-w64-public mailing list > Mingw-w64-public@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/mingw-w64-public > > -- Developer Access Program for Intel Xeon Phi Processors Access to Intel Xeon Phi processor-based developer platforms. With one year of Intel Parallel Studio XE. Training and support from Colfax. Order your platform today. http://sdm.link/xeonphi ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] How to properly print a long long int?
That flag also fixes the return values of certain functions like
vsnprintf where the Microsoft behavior deviated from the standard.
--David
On Tue, Sep 6, 2016 at 3:01 PM, Jeroen Ooms wrote:
> On Tue, Sep 6, 2016 at 8:50 PM, Stefan Weil wrote:
>> I suggest using the ANSI format specifiers ("%lld" is correct in
>> your example) and telling the compiler that you do so. Add
>> -D__USE_MINGW_ANSI_STDIO=1 to the compiler options
>> (or define that macro before including any header files).
>>
>> If you use ANSI format specifiers, those code lines will also
>> work on non-Windows platforms - maybe this is also important
>> for you.
>
> Thank you, that seems to work. Does this flag have any further side
> effects, rather than the format specifiers? Why doesn't mingw-w64
> default to ANSI C when compiling with -std=gnu99 ?
>
> --
> ___
> Mingw-w64-public mailing list
> Mingw-w64-public@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
--
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] How to properly print a long long int?
Having only thought about this for a few minutes, I am guessing that you would need to use the Microsoft-style printf modifier and also use a GCC pragma to suppress the warning: https://gcc.gnu.org/onlinedocs/gcc/Diagnostic-Pragmas.html --David On Tue, Sep 6, 2016 at 9:06 AM, Jeroen Ooms wrote: > How to print a 'long long int' so that it compiles > without -pedantic warnings? I tried: > > long long int number > char i[32]; > sprintf(i, "%lld", number); > > But this gives: warning: unknown conversion type character 'l' in format. I > also tried: > > sprintf(i, "%I64d", number); > > But this gives: warning: ISO C does not support the 'I64' ms_printf length > modifier. > > It's a bit of a silly question but my repository maintainers insist that > code compiles without any pedantic warnings. > -- > ___ > Mingw-w64-public mailing list > Mingw-w64-public@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/mingw-w64-public -- ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Which project are alive?
Julien: MSYS2 is still very actively maintained. You can download it from https://msys2.github.io/ instead of SourceForge. Here is some info about all the work done on MSYS2 in the last week: https://github.com/Alexpux/MINGW-packages/pulse --David Grayson On Tue, Apr 5, 2016 at 10:38 AM, Julien Darthenay wrote: > Hello, > > (I am not sure my message was sent because I forgot to activate my > mailing-list subscription, so I sent it again. Pretty please, excuse me > for the spam if you got this message twice). > > I have installed MinGW64 three years ago, it was something such as > i686-w64-mingw32-gcc-4.8.0-win32_rubenvb. > This year I decided to update it, so I discovered the "new" website > http://mingw-w64.org (not sure it is new, but if it was already there in > 2013 I was not aware of it and never saw it). > > I tried to use Win-Builds. This seem a rather good stuff, installing a > lot of usefull libraries, avoiding me the big pain in the ass to install > them one by one, not even sure I could find all of them. But I realize > this toolchain seems to be somewhat outdated compared to others, still > stuck to MinGW-w64 3.3.0, and last update (1.5) was more than one year > ago. I also got an very annoyous bug > <http://win-builds.org/bugs/index.php?do=details&task_id=137> with gmake > 4.0 64-bit, so I am stuck with using GNU Make 3.82.90 from a previous > installation. Also building 32bits target with Win-builds 64-bits does > not work, so I had to install Win-builds 32-bits. > > I also tried to install MSys2, but I got very disappointed. First thing, > the installer seems to install only for current user (at least it > installed shortcut only for the user who launch installation) but > requires Admin rights to install. This is truly a big flaw that have to > be fixed. But my worst worry was Avast putting a lot of stuff in > quarantine, and after I searched the with DuckDuckGo the messages from > Avast it appears I was being delivered malwares by Soureceforge. So I > immediately removed MSys2. > > At work for some project we are using TDM-GCC, but this tool is not even > mentionned in your download section, this is not reasuring. Also last > news in their website is from 2015 July 2nd. > > And Rubenv toolchain don't seem to be maintained any more. > > So, now that I have finished narrating my story, I have a few questions... > Which of these tools are still alive? > What would you recommend me to use? > I have downloaded a Debian 8.2 32-bit virtual machine, may I use it to > build my how Mingw-64 packages? (Actually I also downloaded the 64-bit > one, but when I tried to run it VMWare insulted me and told me to stop > dreaming, softwares can be very disrespectful nowadays) > Will you do something about the Sourceforge's malwares issue? > What to do if a MinGW package I need is only on Sourcforge? > > Sorry for my disturbing English, and if you have not fallen asleep yet, > thanks for reading me. > > Julien Darthenay > > -- > ___ > Mingw-w64-public mailing list > Mingw-w64-public@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/mingw-w64-public > -- ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [PATCH] Fix data types pid_t and _pid_t for 64 bit Windows
I'm imagining something like this in a header file: pid_t __mingw_posix_getpid(); #ifdef __USE_MINGW_POSIX_PID #define getpid __mingw_posix_getpid #endif So the mingw-w64 binary (the crt?) would always provide __mingw_posix_getpid, but the user program can either use it or not depending on how it is built. Wasn't __USE_MINGW_ANSI_STDIO implemented without making two ABIs? --David On Tue, Mar 1, 2016 at 11:31 AM, Adrien Nader wrote: > On Tue, Mar 01, 2016, David Grayson wrote: >> Could we add a preprocessor configuration option like >> __USE_MINGW_POSIX_PID which makes getpid() actually return a pid_t >> (signed 64-bit integer)? (It can be wrapped in a function named >> __mingw_getpid or something.) So POSIXY projects could opt in to the >> new behavior in their build configuration, and Windowsy projects would >> keep working as is? It would be like __USE_MINGW_ANSI_STDIO. > > Wouldn't that mean two ABIs? Sounds difficult to balance. > > -- > Adrien Nader -- Site24x7 APM Insight: Get Deep Visibility into Application Performance APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month Monitor end-to-end web transactions and take corrective actions now Troubleshoot faster and improve end-user experience. Signup Now! http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140 ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [PATCH] Fix data types pid_t and _pid_t for 64 bit Windows
Could we add a preprocessor configuration option like __USE_MINGW_POSIX_PID which makes getpid() actually return a pid_t (signed 64-bit integer)? (It can be wrapped in a function named __mingw_getpid or something.) So POSIXY projects could opt in to the new behavior in their build configuration, and Windowsy projects would keep working as is? It would be like __USE_MINGW_ANSI_STDIO. --David On Tue, Mar 1, 2016 at 11:08 AM, Eric Blake wrote: > On 03/01/2016 11:54 AM, Stefan Weil wrote: > >> Kai is absolutely right regarding the signedness. I suggest replacing >> "int" by "unsigned" or "unsigned int" in my patch as DWORD and >> unsigned int have the same size for Windows. Feel free to do so >> before committing it (otherwise I'd have to resend it). It's a pity >> that getpid() still has to return an int (because of compatibility >> with the MS getpid()) instead of the normal pid_t. > > NACK. POSIX requires pid_t to be signed. > > http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/sys_types.h.html#tag_13_67 > > blksize_t, pid_t, and ssize_t shall be signed integer types. > > >> >> A short look at the Mingw-w64 code shows several type casts from >> pid_t to DWORD. This code will continue to work with my patch, >> but the type casts are no longer needed. >> >> Regards, >> Stefan >> > > -- > Eric Blake eblake redhat com+1-919-301-3266 > Libvirt virtualization library http://libvirt.org > > > -- > Site24x7 APM Insight: Get Deep Visibility into Application Performance > APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month > Monitor end-to-end web transactions and take corrective actions now > Troubleshoot faster and improve end-user experience. Signup Now! > http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140 > ___ > Mingw-w64-public mailing list > Mingw-w64-public@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/mingw-w64-public > -- Site24x7 APM Insight: Get Deep Visibility into Application Performance APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month Monitor end-to-end web transactions and take corrective actions now Troubleshoot faster and improve end-user experience. Signup Now! http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140 ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [PATCH] Fix data types pid_t and _pid_t for 64 bit Windows
This change would require a lot of 64-bit ingw-w64 libraries and executables to be recompiled, and possibly require code changes, right? Does the use of 64-bit ints for PIDs actually cause any bugs? --David On Feb 28, 2016 7:14 AM, "Stefan Weil" wrote: > Windows always uses 32 bit (int or DWORD) process ids, > even on 64 bit Windows. > > Signed-off-by: Stefan Weil > --- > mingw-w64-headers/crt/sys/types.h| 5 - > mingw-w64-libraries/winpthreads/include/pthread_compat.h | 6 +- > 2 files changed, 1 insertion(+), 10 deletions(-) > > diff --git a/mingw-w64-headers/crt/sys/types.h > b/mingw-w64-headers/crt/sys/types.h > index bc0a54f..be7a01b 100644 > --- a/mingw-w64-headers/crt/sys/types.h > +++ b/mingw-w64-headers/crt/sys/types.h > @@ -56,12 +56,7 @@ typedef unsigned int dev_t; > > #ifndef _PID_T_ > #define_PID_T_ > -#ifndef _WIN64 > typedef int_pid_t; > -#else > -__MINGW_EXTENSION > -typedef __int64_pid_t; > -#endif > > #ifndefNO_OLDNAMES > #undef pid_t > diff --git a/mingw-w64-libraries/winpthreads/include/pthread_compat.h > b/mingw-w64-libraries/winpthreads/include/pthread_compat.h > index 8a3eb61..8d519ea 100644 > --- a/mingw-w64-libraries/winpthreads/include/pthread_compat.h > +++ b/mingw-w64-libraries/winpthreads/include/pthread_compat.h > @@ -70,11 +70,7 @@ > > #include "pthread_time.h" > > -#ifdef _WIN64 > -typedef __int64 pid_t; > -#else > -typedef int pid_t; > -#endif > +typedef int pid_t; > typedef int clockid_t; > > #define WINPTHREADS_INLINE __inline > -- > 2.1.4 > > > > -- > Site24x7 APM Insight: Get Deep Visibility into Application Performance > APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month > Monitor end-to-end web transactions and take corrective actions now > Troubleshoot faster and improve end-user experience. Signup Now! > http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140 > ___ > Mingw-w64-public mailing list > Mingw-w64-public@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/mingw-w64-public > -- Site24x7 APM Insight: Get Deep Visibility into Application Performance APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month Monitor end-to-end web transactions and take corrective actions now Troubleshoot faster and improve end-user experience. Signup Now! http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
