Global objects constructors fail when invokinf standard libs

[ortolano]

Hi,

quite new to wine, and I would like to request help because of something that seemengly should work.
I am testing on versions Stable-1.8.1 and Devel-1.9.4

I managed to recompile and link my win32 application on ARM7 but at execution time, it crashes because of a segmentation fault where memset (or the bare printf("HELLO")) is invoked in the global object constructor.

The global object is built in the stack, then it seems that at launch time my object constructor is called before C Standard Library is ready.
Now, as a workaround I may just declare a pointer to global object and instantiate it in the main (not tried but it should work)...though...this is something I'd like to avoid to keep the code as original as possible. Removing the global objects, everything works like a charm.

As far as I understand, global object constructors are called after Wine infrastructure is ready to go, though I have doubts now regarding C Standard Library.
(Please check 8.3.3. Starting a Winelib process https://www.winehq.org/docs/winedev-guide/x3172)

Am I missing something?

Thanks in advance!

[dimesio]

Wine developers rarely read the forum. You might want to ask this on the developer's mailing list.

[ortolano]

Thanks so much, I'll do as you suggest.

BR

[ortolano]

Hi,

Posted the issue here https://groups.google.com/forum/#!topic ... bkCQ5KW9jI and sent mail to developer's mailing list (I read that suspected bugs should not sent to the list, anyway); still I have no answer.

One last attempt, I'll try to use Wine port of msvcrt, maybe it will work...though can't find there stuff like wmemcpy defined in wchar.h.

[lahmbi5678]

Hi,

wine developers usually aren't excited when contacted via mailing list, they probably are afraid of people spamming them with bug reports, which wouldn't be the purpose of the devel-list. But don't worry. File a bug report in wine's bugzilla and provide a simple test case if possible. That is the usual way to get into contact with wine devs. They actually do read bug reports, just can't fix all of them in a sudden.

You also could try to contact Andre Hentschel, he's doing some ARM development on wine, see https://wiki.winehq.org/User:AndreHentschel

kind regards

[ortolano]

Ok,

I'll file a bug. By the way, reproducing the issue is as simple as the following code:

#include <stdio.h>

class Printer
{
public:
Printer(){printf("HI\n");}
};


Printer p;

int main(void)
{
return 0;
}

***

Compile using msvcrt:

wineg++ -mno-cygwin issue.cpp -o issue

(Compilation without --mno-cygwin does not trigger the error with this code, though I can reproduce it in my application).
Error can be reproduced on both ARM and normal Linux Debian.

Thanks for your attention, BR

[ortolano]

I filed a bug here.

https://bugs.winehq.org/show_bug.cgi?id=40502

[lahmbi5678]

Hi,

I'm sorry, but it seems that nobody picked up your bug report. You should mention in your bug report, that you are on ARM, the "Hardware" property in this bug is set to X86, which is misleading.

You still could try to contact Andre, if you get through his spam filter, he'll probably be able to help you.

kind regards,

[ortolano]

Thanks,

I already got in touch with André, and we both agree this is a general bug: actually I managed to reproduce it also on Debian x86.
This explains the reason I thought it was better not to set ARM on the bug.
I tried to workaround the issue but seems like it is not a configuration issue.

Thanks for your suggestion.