keith I have several problems with this ticket:
well, I am novice here & in TICKETS :).
1. >>You don't have the authority to assign priority.
this was offered by page, so I thought, I must.
2. >>You don't have the authority to assign it to me
I assigned to you, as in TAR archive "libmingwex-5.3.1-mingw32-dll-2.tar.xz" you are mentioned as "user" & "group".
3. >> Why should I take your word for it, anyway?
Why NOT?! if one talks about "importing self procedure" & "absence in exports", probably that one has some knowledge.
4. >>You don't offer a test case.
IF DLL is improper, so it should happen generally, as windows loader will not load DLL & terminate process on stage of initialization. hm.. as novice tried to compile "omp_hello" as suggested "https://www.math.ucla.edu/~wotaoyin/windows_coding.html"; compiler command: "gcc -fopenmp omp_hello.c -o omp_hello"
keith Reply To rosasmje
well, I am novice here & in TICKETS :).
All the more reason for you to read and heed the submission guidelines, which you so obviously, and blithely, skipped past to get to the ticket submission form fields.
1. >>You don't have the authority to assign priority.
this was offered by page, so I thought, I must.
Why? It is clearly listed among the fields which you are instructed to leave alone.
2. >>You don't have the authority to assign it to me
I assigned to you, as in TAR archive "libmingwex-5.3.1-mingw32-dll-2.tar.xz" you are mentioned as "user" & "group".
So what? Once again, you are clearly instructed to leave that field alone. I may have created that tarball, but that places me under no obligation to follow up on related bug reports; it is my prerogative to do so, or not.
3. >> Why should I take your word for it, anyway?
Why NOT?!
Because, as I've already stated, I cannot reproduce your issue. I'm not disputing that you have an issue, but if I can't reproduce it, I can't fix it ... you need to show me how to reproduce the problem; you must not assume that anything will be self-evident.
if one talks about "importing self procedure"
What does that even mean? To me, it conveys absolutely nothing.
& "absence in exports", probably that one has some knowledge.
Absence from exports may mean something ... absence in exports, not so much. Anyway, __emutls_get_address is (correctly) exported by libgcc_s_dw2-1.dll; libmingwex-2.dll isn't expected to export it, but it is expected to access it from libgcc_2_dw2-1.dll.
4. >>You don't offer a test case.
IF DLL is improper, so it should happen generally, as windows loader will not load DLL & terminate process on stage of initialization.
And herein lies the problem with your failure to offer a test case ... my own trivial program, dynamically linked with libmingwex-2.dll does successfully load the DLL, and the process executes to completion, as expected.
hm.. as novice tried to compile "omp_hello" as suggested "https://www.math.ucla.edu/~wotaoyin/windows_coding.html"; compiler command: "gcc -fopenmp omp_hello.c -o omp_hello"
Okay, thanks. I'll try to take a look at that, as and when time permits.
keith)
lets clarify things: I am talking about 32BIT DLL crc32=0x6FF6BB96, size=194062 bytes, from package "libmingwex-5.3.1-mingw32-dll-2.tar.xz".
it Imports function: "__emutls_get_address" from self, e.g. "libmingwex-2.dll". But according to your info, it should be "libgcc_s_dw2-1.dll".
thus, possible explanation: you have properly made DLL of same version, while in package is improperly made DLL, which can't load!
keith)
keith tried to compile "omp_hello" as suggested "https://www.math.ucla.edu/~wotaoyin/windows_coding.html"; compiler command: "gcc -fopenmp omp_hello.c -o omp_hello"
Okay, thanks. I'll try to take a look at that, as and when time permits.
Nope. I still cannot reproduce the issue:
$ wget https://computing.llnl.gov/tutorials/openMP/samples/C/omp_hello.c ... $ mingw32-gcc -fopenmp omp_hello.c -L. -o omp-hello.exe $ mingw32-ldd omp-hello.exe omp-hello.exe +- libmingwex-2.dll +- libgomp-1.dll | +- libgcc_s_dw2-1.dll | +- KERNEL32.dll | +- msvcrt.dll | +- msvcrt.dll +- KERNEL32.dll +- msvcrt.dll $ ./omp-hello.exe Hello World from thread = 0 Number of threads = 2 Hello World from thread = 1
The above is cross-compiled, on Manjaro Linux with mingw32-gcc-9.2.0, and run under Wine-5.8. The "-L." is included in my mingw32-gcc command because I normally link libmingwex.a statically, but I have libmingwex.dll.a in my working directory, to link dynamically, on this occasion. I appreciate that running under Wine may not faithfully mimic native behaviour on Windows, but it is very unusual for Wine to successfully run code which does not run successfully on Windows itself ... the converse is a more likely scenario.
so, is DLL exactly one, as I identified in prev post?
keith Reply To rosasmje
lets clarify things: I am talking about 32BIT DLL crc32=0x6FF6BB96, size=194062 bytes, from package "libmingwex-5.3.1-mingw32-dll-2.tar.xz".
Well, CRC32 does not uniquely identify a file, but that CRC32 and file size match the DLL which I have; if you want better identification, use the SHA256 hash:
$ sha256sum ~/.wine/drive_c/windows/system/libmingwex-2.dll 187fced7ffe32033be0153d0125c586840f38b4743f67dc312b4fcc807b86476 /home/keith/.wine/drive_c/windows/system/libmingwex-2.dll $ cat ~/.wine/drive_c/windows/system/libmingwex-2.dll | gzip -c | tail -c8 | od -t x4 -N 4 -A n 6ff6bb96 $ ls -l ~/.wine/drive_c/windows/system/libmingwex-2.dll -rw-r--r-- 2 keith keith 194062 Apr 30 12:17 /home/keith/.wine/drive_c/windows/system/libmingwex-2.dll
keith Just a thought: where did you get your GCC tool chain? The website to which you referred me earlier suggests that you use tools from MSYS2, a project which illegally distributes packages whose names infringe our legally registered "MinGW" trademark. Needless to say, we do not support such illegally distributed packages.
1. "libmingwex-5.3.1-mingw32-dll-2.tar.xz" is from this site & sha256sum matches. 2. you can use any PE-tools analyzers to view this 'libmingwex-2.dll' & see reported mistake: '__emutls_get_address' import is linked again to 'libmingwex-2.dll'. Windows10 (& for sure olders) will always refuse to load this DLL. So.. it is up to you(? or your group) to fix (or not to fix?)
By the way, I downloaded source of 'mingw-org-wsl', but did not find there any strings matching '__emutls_get_address'.. well I don't know much about C-compilers, so... can't help you to find origin of mistake, but I am sure you can do this.
this mingw looks fun, maybe I will look more at it.. Bye-Bye!
keith)
keith So, you thought you would piss me off some more, by posting two more improperly marked-up comments? The "preview" button is there for a reason ... please use it, before you submit incorrectly marked-up garbage.
By the way, I downloaded source of 'mingw-org-wsl', but did not find there any strings matching '__emutls_get_address'
You will not find it, because it is a libgcc helper, implied when variables are declared with the __thread attribute, (as arising in the new mbrscan.c and wcharmap.c translation units).
you can use any PE-tools analyzers to view this 'libmingwex-2.dll' & see reported mistake: '__emutls_get_address' import is linked again to 'libmingwex-2.dll'
I don't know of any such tools, other than objdump, which I can run on GNU/Linux, (and objdump doesn't really help much here). However, the point is that libmingwex-2.dll is linked with -static-libgcc, which supplies __emutls_get_address(), so that should be embedded within libmingwex-2.dll, without requiring it to be exported.
Windows10 (& for sure olders) will always refuse to load this DLL
It is strange that Wine can do so; thus it seems apparent that the procedure body is appropriately embedded ... otherwise, where is Wine finding it? However, I have managed to resurrect an old WinXP virtual machine, on which I can see the effect you describe; (seems to me, to be yet another Windows deficiency, and thus, another reason to kick it into touch, once and for all time). I can work around this Windows deficiency, in either of two ways:
Of these two, I prefer the latter, (since it doesn't enforce the licensing restriction, for those users who may wish to distribute libmingwex-3.dll dependent applications); I will proceed on this latter basis.
So, you thought you would piss me off some more, by posting two more improperly marked-up comments?
you are overthinking, that someone is in constant try to "piss you off". this is some browser/form related problem. it appears, when I use quotes, & then won't disappear, even if I remove them. see attachment.
I don't know of any such tools, other than objdump
nobody is advised to know anything! but many things exist; & main WWW function is "search"; for example search for 'pe analyzer' brings lots of..
I offer you simple patched DLL, with corrected DLL-name string. so you can distribute properly working DLL, until correction in new version. see attachment.
It is strange that Wine can do so;
Wine can't correct things, it will just ignore. 10 exported functions uses call to emutls_get_address; until they will called, nothing happens bad.
but Now is time to get more strict! software title is: MinGW - Minimalist GNU for Windows; does it says anything about Wine? or Mine? and developers are not even bothering to test development on intended target OS!!??
Reply To rosasmje
but Now is time to get more strict! software title is: MinGW - Minimalist GNU for Windows; does it says anything about Wine? or Mine? and developers are not even bothering to test development on intended target OS!!??
Dear rosasmje,
This project is unfortunately short on developers. Otherwise, some other would quickly catch any defect like this. As it happens, we are thankful enough for Keith to carry on with this project, in any way he can, even if he doesn't have a real need to use a Windows system.
Thanks, Keith.
Regards,
Cesar
keith Reply To rosasmje
So, you thought you would piss me off some more, by posting two more improperly marked-up comments?
you are overthinking, that someone is in constant try to "piss you off". this is some browser/form related problem. it appears, when I use quotes, & then won't disappear, even if I remove them. see attachment.
Wrong! It is a PEBKAC problem ... between your keyboard and chair ... arising out of your own laziness. You are writing markdown code, (which itself, is poorly standardized, but adequately documented here), but you are too lazy to check the conventions for the particular flavour of markdown which is pertinent here; worse still, you are too lazy to even be bothered to use the preview facility, or just too stupid to see that you have inadvertently switched on the underlined text style! FTR, that has nothing to do with quotes, and everything to do with the special meaning of "__", to the markdown interpreter, when you incorrectly wrote "__emutls_get_address", without escaping the "__" markdown code. (The clue, in the preview display, was that the "__" before "emutls_get_address" was not displayed, but the underlined text style was activated).
I don't know of any such tools, other than objdump
nobody is advised to know anything! but many things exist; & main WWW function is "search"; for example search for 'pe analyzer' brings lots of..
Why would I bother? It runs under Wine, so I'm happy, until someone reports a problem on Windows. That I'm willing to pursue this, in spite of your insolent stupidity, should tell you that I'm prepared to take the issue seriously; I could so easily have dismissed you, as the lazy idiot you so clearly are, and closed your ticket as a "won't fix".
I offer you simple patched DLL, with corrected DLL-name string. so you can distribute properly working DLL, until correction in new version. see attachment.
I already have a possible solution, tested on my WinXP virtual machine, for every one of the functions which calls __emutls_get_address, usually indirectly, where the call originates from within libmingwex-3.dll.
It is strange that Wine can do so;
Wine can't correct things, it will just ignore. 10 exported functions uses call to __emutls_get_address; until they will called, nothing happens bad.
Except that Wine doesn't ignore it ... it DTRT, where Windows clearly does not! In any case, when I said that it is "strange that Wine can do so", I meant that I would have expected Wine to better emulate Windows' broken behaviour.
but Now is time to get more strict! software title is: MinGW - Minimalist GNU for Windows; does it says anything about Wine? or Mine? and developers are not even bothering to test development on intended target OS!!??
Well, I don't use Windows ... haven't done so for 20 years, on my own hardware. If it runs under Wine, I assume that it will also run on Windows. Why should I expend effort, and waste my time fighting with a broken OS I've never liked, just to appease a few lusers, who deny the reality that Windows is a truly dreadful apology for an OS? I don't owe those lusers anything ... perhaps if a few of them were to contribute something concrete, instead of yelling BUG, and expecting me to drop everything else to fix it, I could feel more charitable towards them.
Diar keith : ),most of mankind live and die with self-declared belief in self righteousness, finding others "lost in spiteful insolent stupidity" : ) Would you mind to call third persons to audit 'our'>/your case?!
keith I offer you simple patched DLL, with corrected DLL-name string ...
This reintroduces a dynamic libgcc_s_dw2-1.dll dependency, which the original was careful to avoid. IANAL, but am advised by Eli Zaretskii, following a discussion with Richard Stallman, that this does not qualify for the GPL library exemption, and thus requires any dependent code, if distributed, to be published under a GPL compatible licence; i.e. accompanied by full source, not only for libgcc itself, but for the entire application, and must also be unencumbered by any copying or redistribution restrictions, (again, for the entire application). This is not compatible with MinGW licensing policy.
keith Should be fixed, in wsl-5.3.2. Dependent applications should be relinked, with updated libraries.
Reply To keith
Should be fixed, in wsl-5.3.2. Dependent applications should be relinked, with updated libraries.
OK, I updated from installer to 5.3.2. mingwex-3.dll has no problems. this compiles good with linked dll: gcc -fopenmp omp_hello.c -o omp_hello ; But now, with -static addition, compiling fails
f:/mingw/bin/../lib/gcc/mingw32/9.2.0/../../../../mingw32/bin/ld.exe: f:/mingw/bin/../lib/gcc/mingw32/9.2.0/../../..\libmingwex.a(codeset.o):(.text+0x143): undefined reference to GetCPInfo@8'
does mingw needs full reinstall to fix this error?
keith does mingw needs full reinstall to fix this error?
No, it is a separate issue, (which unfortunately, arises due to the resolution of this one). I didn't notice it, because once libmingwex.dll.a is installed into GCC's library path, it does seem to arise only when -static is explicitly specified, and that's not something I do routinely. However, if libmingw32ex.dll.a is not installed, it may become problematic anyway.
The final solution seems to be to add an extra scan of -lmingw32 -lmingwex into the GCC *libgcc spec sequence. Unfortunately, that requires a GCC rebuild, to fix properly, and that isn't a quick fix. As an interim workaround, assuming that you are using GCC-9.2.0, and that you don't already have a custom GCC specs file, you may drop the attached modified GCC-9.2.0 specs file into $MINGW_ROOT/lib/gcc/mingw32/9.2.0/. (If you already have a customized specs file, you will need to edit it, to add the additional -lmingw32 -lmingwex references into the *libgcc specs string. In any case, you will need to adjust $MINGW_ROOT to match whatever drive and directory prefix you've used for your MinGW installation).
Reply To keith
I named this file as 'libgcc.spec'(was I right?) & put there, but this solution not worked. also, I realized, this problem is tied with 'libgopm', as without 'libgopm' simple 'hello' project has no problems with '-static'.
\libmingw32.a(wcharmap.o):(.text+0x208): undefined reference to WideCharToMultiByte@32 \libmingwex.a(codeset.o):(.text+0xbe): undefined reference to GetCPInfo@8 \libmingwex.a(codeset.o):(.text+0x143): undefined reference to GetCPInfo@8
keith Reply To rosasmje
Reply To keith
I named this file as 'libgcc.spec'(was I right?)
No, it must be called specs; the full path name should be c:/mingw/lib/gcc/mingw32/9.2.0/specs, (with appropriate substitution for c:/mingw, if necessary), as that is the only file GCC will read automatically, to override its built-in specs. *libgcc is a label, within that file, for which you would edit the associated spec-string, if you were modifying an existing customized specs file.
& put there, but this solution not worked.
No, it wouldn't, because you named the file incorrectly.
also, I realized, this problem is tied with 'libgopm', as without 'libgopm' simple 'hello' project has no problems with '-static'.
Really? I can reproduce this, and it is not related to libgomp, (which is what I believe you mean, since there is no libgopm in a GCC distribution); it arises, for me, when building other statically linked programs, with no OpenMP dependencies whatsoever, and all build successfully with the extra -lmingw32 -lmingwex scan, but fail with unresolved symbols without it.
Reply To keith OK, with named 'specs' assembly fails with & without -static
"/mingw/bin/../lib/gcc/mingw32/9.2.0/../../../../mingw32/bin/ld.exe: cannot find crt2.o: No such file or directory collect2.exe: error: ld returned 1 exit status"
keith Reply To rosasmje
Reply To keith
OK, with named 'specs' assembly fails with & without -static
"/mingw/bin/../lib/gcc/mingw32/9.2.0/../../../../mingw32/bin/ld.exe: cannot find crt2.o: No such file or directory collect2.exe: error: ld returned 1 exit status"
Well, that's a completely separate issue, which I will not discuss on this ticket.
FTR, crt2.o is provided by mingwrt-5.3.2-mingw32-dev.tar.xz, is installed in $MINGW_ROOT/lib, and I cannot reproduce this unrelated issue. If you want to discuss this further, then please take it to the mailing list, or open a new ticket.
Reply To keith
FTR, crt2.o is provided by mingwrt-5.3.2-mingw32-dev.tar.xz, is installed in $MINGW_ROOT/lib, and I cannot reproduce this unrelated issue.
yes, it is there. probably, this error is due to custom fix with "specs" file. no need new ticket. probably, you will do "GCC rebuild, to fix properly" things.
keith I've reverted the library changes I made, to address this issue, and I've published mingwrt-5.3.3, and w32api-5.3.3 accordingly. With compiler specs unchanged, and a clean rebuild of all libraries, including libmingwex-2.dll, I can no longer reproduce any of the failure conditions identified on this ticket, running under Wine, or in VirtualBox 32-bit guests running either WinXP, or Win7.
I see no reason to pursue this further.
Fork
libmingwex-5.3.1 is BUGGY! it imports from self procedure "__emutls_get_address", while not exporting it. thus any linked app would not start. changed to --static also submitted this as review. also tested Version 5.2.2, it is good; it has not any "__emutls_get_address" inside;