mingw-w64-public — Public Project Mailing List

Re: [Mingw-w64-public] Patch for locking printf

[JonY <jo...@us...>]

On 7/23/2015 06:24, JonY wrote:
> Hi,
> 
> Patch introduces a new macro __MINGW_PRINTF_LOCKING for fprintf and
> vfprintf so when called on the same FILE stream, the operations are not
> overlapped. __USE_MINGW_ANSI_STDIO must also be set for the new macro to
> take effect.
> 
> The reason why it is done in such a way is so programs that already
> doing their own locking will not be affected.
> 
> Idea from user Mateusz of Sourceforge. Patch OK?
> 

Ping?

Re: [Mingw-w64-public] Strange linker error with gcc-5.1 32-bit involving 'virtual thunk'

[Óscar F. <of...@wa...>]

Edward Diener <eld...@tr...>
writes:

>> Calling a virtual member requires an access to the vtable of the class.
>> The vtable is defined on the dll that contains the class' code. If the
>> class is not exported, the vtable is not exported. The errors you are
>> seeing is the linker complaining about the missing vtable.
>
> So you are saying that any class with virtual functions must have the 
> class itself exported rather than the individual member functions when 
> using gcc ? Because with VC++ that is not the case, so it must be an 
> issue with gcc on Windows.

Not sure what VC++ does, exactly, but this:

https://msdn.microsoft.com/en-us/library/81h27t8c.aspx

/quote

If you export one virtual function in a class, you must export all of
them, or at least provide versions that the client can use directly.

If you have a class in which you are using selective member
import/export with virtual functions, the functions must be in the
exportable interface or defined inline (visible to the client).

/end quote

seems to say that you can't export some selected virtual members defined
in .cpp files and hide the rest of the class.

Re: [Mingw-w64-public] Strange linker error with gcc-5.1 32-bit involving 'virtual thunk'

[Edward D. <eld...@tr...>]

On 7/31/2015 9:40 AM, Ruben Van Boxem wrote:
> 2015-07-31 13:07 GMT+02:00 Edward Diener <eld...@tr...
> <mailto:eld...@tr...>>:
>
>     On 7/31/2015 6:05 AM, Ruben Van Boxem wrote:
>     > 2015-07-31 2:04 GMT+02:00 Edward Diener <eld...@tr...
>     <mailto:eld...@tr...>
>      > <mailto:eld...@tr...
>     <mailto:eld...@tr...>>>:
>     >
>     >     On 7/30/2015 10:48 AM, Óscar Fuentes wrote:
>     >     > Edward Diener <eld...@tr...
>     <mailto:eld...@tr...>
>      >
>       <mailto:eld...@tr...
>     <mailto:eld...@tr...>>>
>     >     > writes:
>     >     >
>     >     >>> Another thing is to get some hints from a .map-file.
>     >     >>> Add "-Wl,--print-map,--sort-common,--cref > file.map" at the
>     >     >>> of the link-cmd.
>     >     >>
>     >     >> I could not find any documentation regarding the linker options you
>     >     >> specify in the gcc documentation. Are they mingw-64 specific ? If so
>     >     >> where would thye be documented ?
>     >     >
>     >     > Those are not gcc options, but `ld' (the GNU linker) options.
>     >     >
>     >     > "-Wl" directs gcc to pass the following comma-separated options to ld.
>     >
>     >     To whom do I report this bug ? Does it go to mingw-64, to gcc, to the ld
>     >     linker on Windows ? I have shown this bug occurring through the example
>     >     I posted and I do not think anything I have shown is not standard C++.
>     >     It can be reproduced by anyone. I am not knowledgeable enough about the
>     >     workings of mingw-64/gcc or mingw-64/ld to be able to figure out why
>     >     this bug is occurring but someone knowledgeable enough should be able to
>     >     fix what needs to be fixed.
>     >
>     >
>     > I'm not sure this is a GCC bug. Does the linker error also occur when
>     > using static libraries, and when you dllexport the whole class as
>     > opposed to the functions you're explicitly defining?
>
>     I have tried neither.
>
>
> It would be a helpful experiment.

The reason I did not try it is that the design of the library, which is 
not my own, I am trying to "fix" does not export the whole class, but 
only particular member functions.

In my own design of Windows dlls I always export an entire class but I 
can not overrule the design of someone else's library.

>
>
>     > I believe this error is the same as your previous one: you're not
>     > dllexporting some implictly defined functions.
>
>     Which ones ? You can see the code.
>
>
> As I said in my previous "crystal ball" solution to that problem, it
> would definitely help if c++filt worked again. Hmm, it just occurred to
> me that adding an underscore to the name would change how c++filt looks
> at a name.
> The linker cannot find functions it needs in
>
> ex_xml_exception::~ex_xml_exception()
>
> This function is empty, so there are implicit function definitions at
> play, which as I said, have no reason to be dllexported by default.
>
>
>     > Now, if this is what MSVC
>     > does, perhaps GCC should be modified to follow that behaviour, but that
>     > is not certain at this point.
>
>     It has to be a bug in either gcc or ld using mingw-64 unless you can
>     show me what is wrong with the code which produces the link errors.
>     Unless you tell me that gcc/ld on Windows is incapable of
>     exporting/importing individual member functions of a class rather than
>     the class as a whole this is a bug somewhere in gcc/ld.
>
>
> The thing is, you're not exporting the implicitly defined functions.
> Because you haven't defined them with the dllexport attribute, nor is
> the class as a whole dllexported, do its functions can't inherit that
> attribute.

Which are the implicitly defined functions I must export individually ? 
Note that with the ex_exception class accessed from outside the shared 
library there is no problem but with the ex_xml_exception class there is 
a problem.

>
> Why can you not dllexport the whole class, if I may ask?
> Note that e.g. this web page
> (http://www.codeproject.com/Articles/28969/HowTo-Export-C-classes-from-a-DLL)
> discusses the problems and workarounds. None of the options there says
> to export individual functions. Probably because it leads to exactly
> this type of issue.
>
> Also, I don't think the virtual inheritance has anything to do with it.

Glad to hear that.

Re: [Mingw-w64-public] Strange linker error with gcc-5.1 32-bit involving 'virtual thunk'

[Edward D. <eld...@tr...>]

On 7/31/2015 8:52 AM, Óscar Fuentes wrote:
> Edward Diener <eld...@tr...>
> writes:
>
>>> The code is far from being a minimal example, so I didn't look at it
>>> all, but I see that the class ex_exception is not exported (EX_VISIBLE
>>> expands to "... __visibility__("default")..." and you set
>>> -fvisibility=hidden in your compile command). If your class has virtual
>>> members (as it seems the case) this is asking for trouble.
>>>
>>
>> I am sorry but "this is asking for trouble" means absolutely nothing to
>> me on a technical level.
>
> Calling a virtual member requires an access to the vtable of the class.
> The vtable is defined on the dll that contains the class' code. If the
> class is not exported, the vtable is not exported. The errors you are
> seeing is the linker complaining about the missing vtable.

So you are saying that any class with virtual functions must have the 
class itself exported rather than the individual member functions when 
using gcc ? Because with VC++ that is not the case, so it must be an 
issue with gcc on Windows.

[Mingw-w64-public] Missing CLSIDs and IIDs in msxml2.h

[Matthias-Christian O. <ot...@mi...>]

It seems that msxml2.h is manually generated and therefore many CLSIDs
and IIDs are missing. For example, I had to add the following
definitions for one of my projects:

DEFINE_GUID(IID_ISAXXMLReader, 0xa4f96ed0, 0xf829, 0x476e, 0x81, 0xc0,
0xcd, 0xc7, 0xbd, 0x2a, 0x08, 0x02);
DEFINE_GUID(CLSID_SAXXMLReader30, 0x3124c396, 0xfb13, 0x4836, 0xa6,
0xad, 0x13, 0x17, 0xf1, 0x71, 0x36, 0x88);
DEFINE_GUID(IID_ISAXContentHandler, 0x1545cdfa, 0x9e4e, 0x4497, 0xa8,
0xa4, 0x2b, 0xf7, 0xd0, 0x11, 0x2c, 0x44);
DEFINE_GUID(IID_ISAXErrorHandler, 0xa60511c4, 0xccf5, 0x479e, 0x98,
0xa3, 0xdc, 0x8d, 0xc5, 0x45, 0xb7, 0xd0);
DEFINE_GUID(IID_ISAXLexicalHandler, 0x7f85d5f5, 0x47a8, 0x4497, 0xbd,
0xa5, 0x84, 0xba, 0x04, 0x81, 0x9e, 0xa6);

I suppose it's a wasted effort to manually add the other missing IDs, so
I'm not sending a patch (as suggested in the IRC channel). It seems
better to automatically generate the header with Wine's IDL compiler.
However, I'm not a mingw-w64 developer and could live with the current
#if defined(__MINGW64__) || defined(__MINGW32__) in my code.

- Matthias-Christian Ott

Re: [Mingw-w64-public] Strange linker error with gcc-5.1 32-bit involving 'virtual thunk'

[Ruben V. B. <van...@gm...>]

2015-07-31 13:07 GMT+02:00 Edward Diener <eld...@tr...>:

> On 7/31/2015 6:05 AM, Ruben Van Boxem wrote:
> > 2015-07-31 2:04 GMT+02:00 Edward Diener <eld...@tr...
> > <mailto:eld...@tr...>>:
> >
> >     On 7/30/2015 10:48 AM, Óscar Fuentes wrote:
> >     > Edward Diener <eld...@tr...
> >     <mailto:eld...@tr...>>
> >     > writes:
> >     >
> >     >>> Another thing is to get some hints from a .map-file.
> >     >>> Add "-Wl,--print-map,--sort-common,--cref > file.map" at the
> >     >>> of the link-cmd.
> >     >>
> >     >> I could not find any documentation regarding the linker options
> you
> >     >> specify in the gcc documentation. Are they mingw-64 specific ? If
> so
> >     >> where would thye be documented ?
> >     >
> >     > Those are not gcc options, but `ld' (the GNU linker) options.
> >     >
> >     > "-Wl" directs gcc to pass the following comma-separated options to
> ld.
> >
> >     To whom do I report this bug ? Does it go to mingw-64, to gcc, to
> the ld
> >     linker on Windows ? I have shown this bug occurring through the
> example
> >     I posted and I do not think anything I have shown is not standard
> C++.
> >     It can be reproduced by anyone. I am not knowledgeable enough about
> the
> >     workings of mingw-64/gcc or mingw-64/ld to be able to figure out why
> >     this bug is occurring but someone knowledgeable enough should be
> able to
> >     fix what needs to be fixed.
> >
> >
> > I'm not sure this is a GCC bug. Does the linker error also occur when
> > using static libraries, and when you dllexport the whole class as
> > opposed to the functions you're explicitly defining?
>
> I have tried neither.
>

It would be a helpful experiment.


>
> > I believe this error is the same as your previous one: you're not
> > dllexporting some implictly defined functions.
>
> Which ones ? You can see the code.
>

As I said in my previous "crystal ball" solution to that problem, it would
definitely help if c++filt worked again. Hmm, it just occurred to me that
adding an underscore to the name would change how c++filt looks at a name.
The linker cannot find functions it needs in

ex_xml_exception::~ex_xml_exception()

This function is empty, so there are implicit function definitions at
play, which as I said, have no reason to be dllexported by default.


> > Now, if this is what MSVC
> > does, perhaps GCC should be modified to follow that behaviour, but that
> > is not certain at this point.
>
> It has to be a bug in either gcc or ld using mingw-64 unless you can
> show me what is wrong with the code which produces the link errors.
> Unless you tell me that gcc/ld on Windows is incapable of
> exporting/importing individual member functions of a class rather than
> the class as a whole this is a bug somewhere in gcc/ld.
>

The thing is, you're not exporting the implicitly defined functions.
Because you haven't defined them with the dllexport attribute, nor is the
class as a whole dllexported, do its functions can't inherit that attribute.

Why can you not dllexport the whole class, if I may ask?
Note that e.g. this web page (
http://www.codeproject.com/Articles/28969/HowTo-Export-C-classes-from-a-DLL)
discusses the problems and workarounds. None of the options there says to
export individual functions. Probably because it leads to exactly this type
of issue.

Also, I don't think the virtual inheritance has anything to do with it.

Ruben


>
>
>
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Mingw-w64-public mailing list
> Min...@li...
> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
>

Re: [Mingw-w64-public] Strange linker error with gcc-5.1 32-bit involving 'virtual thunk'

[Óscar F. <of...@wa...>]

Edward Diener <eld...@tr...>
writes:

>> The code is far from being a minimal example, so I didn't look at it
>> all, but I see that the class ex_exception is not exported (EX_VISIBLE
>> expands to "... __visibility__("default")..." and you set
>> -fvisibility=hidden in your compile command). If your class has virtual
>> members (as it seems the case) this is asking for trouble.
>>
>
> I am sorry but "this is asking for trouble" means absolutely nothing to 
> me on a technical level.

Calling a virtual member requires an access to the vtable of the class.
The vtable is defined on the dll that contains the class' code. If the
class is not exported, the vtable is not exported. The errors you are
seeing is the linker complaining about the missing vtable.

[snip]

Re: [Mingw-w64-public] Strange linker error with gcc-5.1 32-bit involving 'virtual thunk'

[Edward D. <eld...@tr...>]

On 7/31/2015 7:45 AM, Óscar Fuentes wrote:
> Edward Diener <eld...@tr...>
> writes:
>
>>> I'm not sure this is a GCC bug. Does the linker error also occur when
>>> using static libraries, and when you dllexport the whole class as
>>> opposed to the functions you're explicitly defining?
>>
>> I have tried neither.
>>
>>> I believe this error is the same as your previous one: you're not
>>> dllexporting some implictly defined functions.
>>
>> Which ones ? You can see the code.
>
> The code is far from being a minimal example, so I didn't look at it
> all, but I see that the class ex_exception is not exported (EX_VISIBLE
> expands to "... __visibility__("default")..." and you set
> -fvisibility=hidden in your compile command). If your class has virtual
> members (as it seems the case) this is asking for trouble.
>

I am sorry but "this is asking for trouble" means absolutely nothing to 
me on a technical level.

>>> Now, if this is what MSVC
>>> does, perhaps GCC should be modified to follow that behaviour, but that
>>> is not certain at this point.
>>
>> It has to be a bug in either gcc or ld using mingw-64 unless you can
>> show me what is wrong with the code which produces the link errors.
>> Unless you tell me that gcc/ld on Windows is incapable of
>> exporting/importing individual member functions of a class rather than
>> the class as a whole this is a bug somewhere in gcc/ld.
>
> As you know C++ requires more info than the member address/signature to
> be able to call that method when it is virtual or there are some
> constructor/copier/etc involved.

No, I don't know what you are saying. Please be explicit and tell me 
what is lacking in my code.

I realize that you and Ruben are trying to help me figure out what I 
need to do in order not to get the link errors I have showed in my 
example, but unless you can be specific as to what has to change in the 
code, which looks perfectly fine AFAICS, vague comments are not going to 
solve this problem. I can assure you that I have enough C++ expertise to 
understand whatever specific things you want to tell me.

If you tell me that exporting/importing individual functions of a class 
does not work with mingw-64/gcc/ld when virtual inheritance is involved, 
that's fine but I would like to see some sort of docs explaining this. 
In fact if there are docs explaining all the rules of 
exporting/importing individual functions of a class using mingw-64/gcc I 
will be glad to read them.

The code example I have shown is a very simplified version of a much 
larger situation in the build of the Boost serialization library, but it 
shows the problem in building the library adequately. I am trying to 
help debug problems in building the wide character version of the 
library using gcc on Windows. I did not design and code any portion of 
the original library so I am trying to minimize any one-off changes that 
have to be made to build the wide character version of the library using 
mingw-64/gcc. Therefore I am very concerned at making the absolutely 
minimal number of changes necessary to get the code to build and work 
properly.

Re: [Mingw-w64-public] Strange linker error with gcc-5.1 32-bit involving 'virtual thunk'

[Óscar F. <of...@wa...>]

Edward Diener <eld...@tr...>
writes:

>> I'm not sure this is a GCC bug. Does the linker error also occur when
>> using static libraries, and when you dllexport the whole class as
>> opposed to the functions you're explicitly defining?
>
> I have tried neither.
>
>> I believe this error is the same as your previous one: you're not
>> dllexporting some implictly defined functions.
>
> Which ones ? You can see the code.

The code is far from being a minimal example, so I didn't look at it
all, but I see that the class ex_exception is not exported (EX_VISIBLE
expands to "... __visibility__("default")..." and you set
-fvisibility=hidden in your compile command). If your class has virtual
members (as it seems the case) this is asking for trouble.

>> Now, if this is what MSVC
>> does, perhaps GCC should be modified to follow that behaviour, but that
>> is not certain at this point.
>
> It has to be a bug in either gcc or ld using mingw-64 unless you can 
> show me what is wrong with the code which produces the link errors. 
> Unless you tell me that gcc/ld on Windows is incapable of 
> exporting/importing individual member functions of a class rather than 
> the class as a whole this is a bug somewhere in gcc/ld.

As you know C++ requires more info than the member address/signature to
be able to call that method when it is virtual or there are some
constructor/copier/etc involved.

Re: [Mingw-w64-public] Strange linker error with gcc-5.1 32-bit involving 'virtual thunk'

[Edward D. <eld...@tr...>]

On 7/31/2015 6:05 AM, Ruben Van Boxem wrote:
> 2015-07-31 2:04 GMT+02:00 Edward Diener <eld...@tr...
> <mailto:eld...@tr...>>:
>
>     On 7/30/2015 10:48 AM, Óscar Fuentes wrote:
>     > Edward Diener <eld...@tr...
>     <mailto:eld...@tr...>>
>     > writes:
>     >
>     >>> Another thing is to get some hints from a .map-file.
>     >>> Add "-Wl,--print-map,--sort-common,--cref > file.map" at the
>     >>> of the link-cmd.
>     >>
>     >> I could not find any documentation regarding the linker options you
>     >> specify in the gcc documentation. Are they mingw-64 specific ? If so
>     >> where would thye be documented ?
>     >
>     > Those are not gcc options, but `ld' (the GNU linker) options.
>     >
>     > "-Wl" directs gcc to pass the following comma-separated options to ld.
>
>     To whom do I report this bug ? Does it go to mingw-64, to gcc, to the ld
>     linker on Windows ? I have shown this bug occurring through the example
>     I posted and I do not think anything I have shown is not standard C++.
>     It can be reproduced by anyone. I am not knowledgeable enough about the
>     workings of mingw-64/gcc or mingw-64/ld to be able to figure out why
>     this bug is occurring but someone knowledgeable enough should be able to
>     fix what needs to be fixed.
>
>
> I'm not sure this is a GCC bug. Does the linker error also occur when
> using static libraries, and when you dllexport the whole class as
> opposed to the functions you're explicitly defining?

I have tried neither.

> I believe this error is the same as your previous one: you're not
> dllexporting some implictly defined functions.

Which ones ? You can see the code.

> Now, if this is what MSVC
> does, perhaps GCC should be modified to follow that behaviour, but that
> is not certain at this point.

It has to be a bug in either gcc or ld using mingw-64 unless you can 
show me what is wrong with the code which produces the link errors. 
Unless you tell me that gcc/ld on Windows is incapable of 
exporting/importing individual member functions of a class rather than 
the class as a whole this is a bug somewhere in gcc/ld.

Re: [Mingw-w64-public] Strange linker error with gcc-5.1 32-bit involving 'virtual thunk'

[Ruben V. B. <van...@gm...>]

2015-07-31 2:04 GMT+02:00 Edward Diener <eld...@tr...>:

> On 7/30/2015 10:48 AM, Óscar Fuentes wrote:
> > Edward Diener <eld...@tr...>
> > writes:
> >
> >>> Another thing is to get some hints from a .map-file.
> >>> Add "-Wl,--print-map,--sort-common,--cref > file.map" at the
> >>> of the link-cmd.
> >>
> >> I could not find any documentation regarding the linker options you
> >> specify in the gcc documentation. Are they mingw-64 specific ? If so
> >> where would thye be documented ?
> >
> > Those are not gcc options, but `ld' (the GNU linker) options.
> >
> > "-Wl" directs gcc to pass the following comma-separated options to ld.
>
> To whom do I report this bug ? Does it go to mingw-64, to gcc, to the ld
> linker on Windows ? I have shown this bug occurring through the example
> I posted and I do not think anything I have shown is not standard C++.
> It can be reproduced by anyone. I am not knowledgeable enough about the
> workings of mingw-64/gcc or mingw-64/ld to be able to figure out why
> this bug is occurring but someone knowledgeable enough should be able to
> fix what needs to be fixed.
>

I'm not sure this is a GCC bug. Does the linker error also occur when using
static libraries, and when you dllexport the whole class as opposed to the
functions you're explicitly defining?
I believe this error is the same as your previous one: you're not
dllexporting some implictly defined functions. Now, if this is what MSVC
does, perhaps GCC should be modified to follow that behaviour, but that is
not certain at this point.

Ruben

>
>
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Mingw-w64-public mailing list
> Min...@li...
> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
>

Re: [Mingw-w64-public] GCC 5.2 with JIT language frontend

[niXman <i.n...@au...>]

Hayden Livingston 2015-07-30 21:19:
> Hi,
> 
> I'm getting this error from make, and have no idea how to fix it? I
> got this previously as well, when I tried to build GCC without using
> your build scripts.
> 
> Searching around it says that maybe it is related to not configuring
> the right directory, but I'm positive I've done it correctly and also
> this time I just used your build scripts, so unless I need to run them
> from a specific place. What gives?
> 
> make[2]: *** No rule to make target
> '../build-x86_64-w64-mingw32/libiberty/pic/libiberty.a', needed by
> 'build/genmddeps.exe'.  Stop.
> make[2]: Leaving directory
> '/home/halivingston/mingw-gcc-5.2.0/x86_64-520-posix-sjlj-rt_v4/build/gcc-5.2.0/gcc'
> Makefile:4125: recipe for target 'all-gcc' failed
> make[1]: *** [all-gcc] Error 2
> make[1]: Leaving directory
> '/home/halivingston/mingw-gcc-5.2.0/x86_64-520-posix-sjlj-rt_v4/build/gcc-5.2.0'
> Makefile:879: recipe for target 'all' failed
> make: *** [all] Error 2

Hi,

Firstly, try to build the GCC using the default settings. And only after 
that, if the build is successful, add additional options.

P.S.
Please sync your local copy of mingw-builds with origin.

build command:
./build --mode=gcc-5.2.0 --buildroot=/home/halivingston/gcc-5.2.0 
--threads=posix --exceptions=sjlj --arch=x86_64

Re: [Mingw-w64-public] Unicode file names and globbing in a console application.

[waterlan <wat...@xs...>]

waterlan schreef op 2015-07-07 20:40:
> Hi,
> 
> My console application (dos2unix) has globbing enabled:
> 
> 
> int main (int argc, char *argv[])
> {
> # ifdef __MINGW64__
>    int _dowildcard = -1; /* enable wildcard expansion for Win64 */
> # endif
> 
> 
> This works fine for ANSI names. But, in order to open files with 
> unicode
> names, I'm converting the arguments to wide arguments.
> 
> 
>    wchar_t **wargv;
>    wargv = CommandLineToArgvW(GetCommandLineW(), &argc);
> 
> 
> The wide arguments wargv are not globbed. When I try to open files, I
> get this kind of errors:
> 
> 
> c:\tmp>dos2unix *.txt
>   *.txt: No such file or directory
> 
> 
> Is there a way to get a globbed file list of wide arguments in a 
> console
> application?

Hi,

I solved it by making my own wide globbing function. I take the wide 
arguments from CommandLineToArgvW(), I glob them and convert the result 
to UTF-8. The function returns a normal char** type arg list with all 
the file names in UTF-8 encoding. Because all the program's command line 
options are ASCII, I don't need to change anything in the command line 
parsing function. On the few places where I access the file system I 
created small wrapper functions that convert the UTF-8 file names back 
to wchar_t names, so I can use the wide functions to access the files 
(e.g. _wfopen instead of fopen). This way the change to my code was 
minimal and stays portable.

If you want to see the code check out the latest version of dos2unix 
(7.3-beta5).

best regards,

-- 
Erwin Waterlander
http://waterlan.home.xs4all.nl/

Re: [Mingw-w64-public] Strange linker error with gcc-5.1 32-bit involving 'virtual thunk'

[Edward D. <eld...@tr...>]

On 7/30/2015 10:48 AM, Óscar Fuentes wrote:
> Edward Diener <eld...@tr...>
> writes:
>
>>> Another thing is to get some hints from a .map-file.
>>> Add "-Wl,--print-map,--sort-common,--cref > file.map" at the
>>> of the link-cmd.
>>
>> I could not find any documentation regarding the linker options you
>> specify in the gcc documentation. Are they mingw-64 specific ? If so
>> where would thye be documented ?
>
> Those are not gcc options, but `ld' (the GNU linker) options.
>
> "-Wl" directs gcc to pass the following comma-separated options to ld.

To whom do I report this bug ? Does it go to mingw-64, to gcc, to the ld 
linker on Windows ? I have shown this bug occurring through the example 
I posted and I do not think anything I have shown is not standard C++. 
It can be reproduced by anyone. I am not knowledgeable enough about the 
workings of mingw-64/gcc or mingw-64/ld to be able to figure out why 
this bug is occurring but someone knowledgeable enough should be able to 
fix what needs to be fixed.

Re: [Mingw-w64-public] GCC 5.2 with JIT language frontend

[Hayden L. <hal...@gm...>]

Hi,

I'm getting this error from make, and have no idea how to fix it? I
got this previously as well, when I tried to build GCC without using
your build scripts.

Searching around it says that maybe it is related to not configuring
the right directory, but I'm positive I've done it correctly and also
this time I just used your build scripts, so unless I need to run them
from a specific place. What gives?

make[2]: *** No rule to make target
'../build-x86_64-w64-mingw32/libiberty/pic/libiberty.a', needed by
'build/genmddeps.exe'.  Stop.
make[2]: Leaving directory
'/home/halivingston/mingw-gcc-5.2.0/x86_64-520-posix-sjlj-rt_v4/build/gcc-5.2.0/gcc'
Makefile:4125: recipe for target 'all-gcc' failed
make[1]: *** [all-gcc] Error 2
make[1]: Leaving directory
'/home/halivingston/mingw-gcc-5.2.0/x86_64-520-posix-sjlj-rt_v4/build/gcc-5.2.0'
Makefile:879: recipe for target 'all' failed
make: *** [all] Error 2

On Thu, Jul 30, 2015 at 3:36 AM, Hayden Livingston
<hal...@gm...> wrote:
> Awesome, going to try that, btw I think it also needs
> --enable-host-shared, but I'll try with your suggestion only and see
> where I get.
>
> On Thu, Jul 30, 2015 at 3:28 AM, niXman <i.n...@au...> wrote:
>> Hayden Livingston 2015-07-30 13:19:
>>> Hi,
>>>
>>> I couldn't see an option to enable jit, it's not on the repo or are
>>> you saying if I pass it your script will still work?
>>
>> Yes, you should to add the 'jit' here(for gcc-5.2):
>> https://github.com/niXman/mingw-builds/blob/develop/scripts/gcc-5.2.0.sh#L82
>>
>> Use the 'develop' branch.
>>
>>
>> ------------------------------------------------------------------------------
>> _______________________________________________
>> Mingw-w64-public mailing list
>> Min...@li...
>> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] [PATCH] 2 Small Patches for ARM and Clang building

[Martell M. <mar...@gm...>]

diff --git a/mingw-w64-crt/Makefile.am b/mingw-w64-crt/Makefile.am
index 8b91f0c..30cc247 100644
--- a/mingw-w64-crt/Makefile.am
+++ b/mingw-w64-crt/Makefile.am
@@ -395,7 +395,7 @@ if LIB32
 # Compiling 32-bit runtime
 #
 
-lib32dir=$(prefix)/@LIB32SUFFIXDIR@
+lib32dir=$(prefix)/@LIBX8632SUFFIXDIR@
 crt32dir=$(lib32dir)
 winrt32dir=$(lib32dir)
 dx32dir=$(lib32dir)
@@ -660,7 +660,7 @@ if LIB64
 # Compiling 64-bit runtime
 # #######################################################################
 
-lib64dir=$(prefix)/@LIB64SUFFIXDIR@
+lib64dir=$(prefix)/@LIBX8664SUFFIXDIR@
 crt64dir=$(lib64dir)
 winrt64dir=$(lib64dir)
 dx64dir=$(lib64dir)
diff --git a/mingw-w64-crt/configure.ac b/mingw-w64-crt/configure.ac
index bcf7d0c..788779c 100644
--- a/mingw-w64-crt/configure.ac
+++ b/mingw-w64-crt/configure.ac
@@ -121,23 +121,43 @@ AS_VAR_IF([enable_libarm32],[yes],[
 
 AS_CASE([$host_cpu],
   [x86_64],[
-    lib64suffx=lib
-    lib32suffx=lib32],
+    libx8664suffx=lib
+    libx8632suffx=lib32
+    libarm64suffx=libarm64
+    libarm32suffx=libarm32],
   [i*86],[
-    lib64suffx=lib64
-    lib32suffx=lib],
+    libx8664suffx=lib64
+    libx8632suffx=lib
+    libarm64suffx=libarm64
+    libarm32suffx=libarm32],
+  [aarch64*],[
+    libx8664suffx=libx8664
+    libx8632suffx=libx8632
+    libarm64suffx=lib
+    libarm32suffx=lib32],
+  [armv7*],[
+    libx8664suffx=libx8664
+    libx8632suffx=libx8632
+    libarm64suffx=lib64
+    libarm32suffx=lib],
   [
-    lib64suffx=lib64
-    lib32suffx=lib32]
+    libx8664suffx=libx8664
+    libx8632suffx=libx8632
+    libarm64suffx=libarm64
+    libarm32suffx=libarm32]
 )
 
 AS_VAR_IF([enable_w32api],[yes],[
-  lib64suffx=$lib64suffx/w32api
-  lib32suffx=$lib32suffx/w32api
+  libx8664suffx=$libx8664suffx/w32api
+  libx8632suffx=$libx8632suffx/w32api
+  libarm64suffx=$libarm64suffx/w32api
+  libarm32suffx=$libarm32suffx/w32api
 ])
 
-AC_SUBST([LIB64SUFFIXDIR],[$lib64suffx])
-AC_SUBST([LIB32SUFFIXDIR],[$lib32suffx])
+AC_SUBST([LIBX8664SUFFIXDIR],[$libx8664suffx])
+AC_SUBST([LIBX8632SUFFIXDIR],[$libx8632suffx])
+AC_SUBST([LIBARM64SUFFIXDIR],[$libarm64suffx])
+AC_SUBST([LIBARM32SUFFIXDIR],[$libarm32suffx])
 
 # Checks for features.
 

Re: [Mingw-w64-public] Strange linker error with gcc-5.1 32-bit involving 'virtual thunk'

[Edward D. <eld...@tr...>]

On 7/30/2015 10:48 AM, Óscar Fuentes wrote:
> Edward Diener <eld...@tr...>
> writes:
>
>>> Another thing is to get some hints from a .map-file.
>>> Add "-Wl,--print-map,--sort-common,--cref > file.map" at the
>>> of the link-cmd.
>>
>> I could not find any documentation regarding the linker options you
>> specify in the gcc documentation. Are they mingw-64 specific ? If so
>> where would thye be documented ?
>
> Those are not gcc options, but `ld' (the GNU linker) options.
>
> "-Wl" directs gcc to pass the following comma-separated options to ld.
>
>
> ------------------------------------------------------------------------------
>

Thanks, I was able to pass the options to ld and get a map file for both 
shared libraries. Unfortunately even with the map files, which are 
pretty extensive, I cannot decipher why the link is failing.

Re: [Mingw-w64-public] Strange linker error with gcc-5.1 32-bit involving 'virtual thunk'

[Óscar F. <of...@wa...>]

Edward Diener <eld...@tr...>
writes:

>> Another thing is to get some hints from a .map-file.
>> Add "-Wl,--print-map,--sort-common,--cref > file.map" at the
>> of the link-cmd.
>
> I could not find any documentation regarding the linker options you 
> specify in the gcc documentation. Are they mingw-64 specific ? If so 
> where would thye be documented ?

Those are not gcc options, but `ld' (the GNU linker) options.

"-Wl" directs gcc to pass the following comma-separated options to ld.

Re: [Mingw-w64-public] Strange linker error with gcc-5.1 32-bit involving 'virtual thunk'

[Edward D. <eld...@tr...>]

On 7/30/2015 2:48 AM, Gisle Vanem wrote:
> Edward Diener wrote:
>
>> If I remove the declaration and definition of ex_xml_exception::what(),
>> since it is not needed, when linking I get:
>>
>> throw_exception_ex.o:throw_exception_ex.cpp:(.rdata$_ZTV16ex_xml_exception[__ZTV16ex_xml_exception]+0x20):
>> undefined reference to `virtual thunk to ex_exception::what() const'
>> throw_exception_ex.o:throw_exception_ex.cpp:(.rdata$_ZTC16ex_xml_exception4_12ex_exception[__ZTC16ex_xml_exception4_12ex_exception]+0x38):
>> undefined reference to `virtual thunk to ex_exception::what() const'
>> collect2.exe: error: ld returned 1 exit status
>
> AFAICS, that is because you have virtualised the whole 'ex_exception'
> class in your 'ex_xml_exception' class. Why? What happens if you virtualise
> only those functions you need to specialize?
>
> Another thing is to get some hints from a .map-file.
> Add "-Wl,--print-map,--sort-common,--cref > file.map" at the
> of the link-cmd.

I could not find any documentation regarding the linker options you 
specify in the gcc documentation. Are they mingw-64 specific ? If so 
where would thye be documented ?

Re: [Mingw-w64-public] GCC 5.2 with JIT language frontend

[Hayden L. <hal...@gm...>]

Awesome, going to try that, btw I think it also needs
--enable-host-shared, but I'll try with your suggestion only and see
where I get.

On Thu, Jul 30, 2015 at 3:28 AM, niXman <i.n...@au...> wrote:
> Hayden Livingston 2015-07-30 13:19:
>> Hi,
>>
>> I couldn't see an option to enable jit, it's not on the repo or are
>> you saying if I pass it your script will still work?
>
> Yes, you should to add the 'jit' here(for gcc-5.2):
> https://github.com/niXman/mingw-builds/blob/develop/scripts/gcc-5.2.0.sh#L82
>
> Use the 'develop' branch.
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Mingw-w64-public mailing list
> Min...@li...
> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] GCC 5.2 with JIT language frontend

[niXman <i.n...@au...>]

Hayden Livingston 2015-07-30 13:19:
> Hi,
> 
> I couldn't see an option to enable jit, it's not on the repo or are
> you saying if I pass it your script will still work?

Yes, you should to add the 'jit' here(for gcc-5.2):
https://github.com/niXman/mingw-builds/blob/develop/scripts/gcc-5.2.0.sh#L82

Use the 'develop' branch.

Re: [Mingw-w64-public] GCC 5.2 with JIT language frontend

[Hayden L. <hal...@gm...>]

 Hi,

I couldn't see an option to enable jit, it's not on the repo or are
you saying if I pass it your script will still work?

On Thu, Jul 30, 2015 at 3:07 AM, niXman <i.n...@au...> wrote:
> Hayden Livingston 2015-07-30 05:56:
>
> Hi,
>
>> Are you saying that this is a way to get a windows 64-bit build?
> Yes, 32 and 64 bit.
>
>> Or are you saying you've got JIT frontend working?
> I was able to build the GCC with the '--enable-languages=jit' option.
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Mingw-w64-public mailing list
> Min...@li...
> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] GCC 5.2 with JIT language frontend

[niXman <i.n...@au...>]

Hayden Livingston 2015-07-30 05:56:

Hi,

> Are you saying that this is a way to get a windows 64-bit build?
Yes, 32 and 64 bit.

> Or are you saying you've got JIT frontend working?
I was able to build the GCC with the '--enable-languages=jit' option.

Re: [Mingw-w64-public] Strange linker error with gcc-5.1 32-bit involving 'virtual thunk'

[Edward D. <eld...@tr...>]

On 7/30/2015 2:48 AM, Gisle Vanem wrote:
> Edward Diener wrote:
>
>> If I remove the declaration and definition of ex_xml_exception::what(),
>> since it is not needed, when linking I get:
>>
>> throw_exception_ex.o:throw_exception_ex.cpp:(.rdata$_ZTV16ex_xml_exception[__ZTV16ex_xml_exception]+0x20):
>> undefined reference to `virtual thunk to ex_exception::what() const'
>> throw_exception_ex.o:throw_exception_ex.cpp:(.rdata$_ZTC16ex_xml_exception4_12ex_exception[__ZTC16ex_xml_exception4_12ex_exception]+0x38):
>> undefined reference to `virtual thunk to ex_exception::what() const'
>> collect2.exe: error: ld returned 1 exit status
>
> AFAICS, that is because you have virtualised the whole 'ex_exception'
> class in your 'ex_xml_exception' class.

It is perfectly valid C++ to do so. Why should I get a gcc linker error 
for valid C++ code ?

> Why?

I am simply duplicating in a much simplified form code that exists 
elsewhere, trying to solve a far more complicated problem not of my own 
originally.

> What happens if you virtualise
> only those functions you need to specialize?

I can try that. Please understand that the issue is not what may work 
but why valid C++ will not work.

>
> Another thing is to get some hints from a .map-file.
> Add "-Wl,--print-map,--sort-common,--cref > file.map" at the
> of the link-cmd.

I will try that to see if the .map file will tell me anything about the 
linker error I am getting.

Re: [Mingw-w64-public] Strange linker error with gcc-5.1 32-bit involving 'virtual thunk'

[Gisle V. <gv...@ya...>]

Edward Diener wrote:

> If I remove the declaration and definition of ex_xml_exception::what(),
> since it is not needed, when linking I get:
>
> throw_exception_ex.o:throw_exception_ex.cpp:(.rdata$_ZTV16ex_xml_exception[__ZTV16ex_xml_exception]+0x20):
> undefined reference to `virtual thunk to ex_exception::what() const'
> throw_exception_ex.o:throw_exception_ex.cpp:(.rdata$_ZTC16ex_xml_exception4_12ex_exception[__ZTC16ex_xml_exception4_12ex_exception]+0x38):
> undefined reference to `virtual thunk to ex_exception::what() const'
> collect2.exe: error: ld returned 1 exit status

AFAICS, that is because you have virtualised the whole 'ex_exception'
class in your 'ex_xml_exception' class. Why? What happens if you virtualise
only those functions you need to specialize?

Another thing is to get some hints from a .map-file.
Add "-Wl,--print-map,--sort-common,--cref > file.map" at the
of the link-cmd.

-- 
--gv