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 <[email protected]> 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 <[email protected]> > > 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 > > [email protected] > > 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 > [email protected] > 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 [email protected] https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
