Ticket #40438

Bug in libmingwex-5.3.1 dll

Date d'ouverture: 2020-05-23 18:07 Dernière mise à jour: 2020-06-04 06:35

Rapporteur:
Propriétaire:
Type:
État:
Atteints
Composant:
Jalon:
(Aucun)
Priorité:
2
Sévérité:
5 - moyen
Résolution:
Fixed
Fichier:
3
Vote
Score: 0
No votes
0.0% (0/0)
0.0% (0/0)

Détails

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;

Ticket History (3/30 Histories)

2020-05-23 18:07 Updated by: rosasmje
  • New Ticket "Bug in libmingwex-5.3.1 dll" created
2020-05-23 19:14 Updated by: keith
  • Priorité Update from 8 to 2
  • Details Updated
Commentaire

I have several problems with this ticket:

  • While it may be valid as a ticket item, it most definitely does not merit a blaring review item headline.
  • You don't have the authority to assign it to me. I'll accept it, since I would have taken it anyway, but you pissed me off, by failing to follow the submission guidelines, (which are shown at the top of the form you completed, to create the ticket).
  • You don't have the authority to assign priority. Now I'm doubly pissed off, so I've downgraded it, below default, by one level for each by which you deigned to escalate it.
  • Why should I take your word for it, anyway? You don't offer a test case, and I see no supporting evidence in my own work. I cannot, and do not know how to, reproduce your issue; could it possibly be related to this mailing list post?
  • I'm triply pissed off, because you couldn't be bothered to preview your ticket, before posting in improperly marked-up, borderline illegible format, (thus, forcing me to adjust your bad mark-up).
2020-05-23 19:44 Updated by: rosasmje
Commentaire

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"

2020-05-24 00:10 Updated by: keith
Commentaire

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.

(Edited, 2020-05-24 00:16 Updated by: keith)
2020-05-24 00:53 Updated by: rosasmje
Commentaire

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!

(Edited, 2020-05-24 18:52 Updated by: keith)
2020-05-24 01:14 Updated by: keith
Commentaire

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.

2020-05-24 01:59 Updated by: rosasmje
Commentaire

so, is DLL exactly one, as I identified in prev post?

2020-05-24 03:25 Updated by: keith
Commentaire

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

2020-05-24 03:36 Updated by: keith
Commentaire

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.

2020-05-24 05:14 Updated by: rosasmje
Commentaire

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!

(Edited, 2020-05-24 18:51 Updated by: keith)
2020-05-27 05:56 Updated by: keith
Commentaire

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:

  • Do not link libmingwex-2.dll with -static-libgcc, thus introducing an implicit dynamic dependency on libgcc_s_dw2-1.dll, (and thus, incurring the licensing restrictions on redistribution, which are inherent in this dependency).
  • Move the mbrscan.o and wcharmap.o modules out of libmingwex-2.dll, (thus necessitating an interface version bump to libmingwex-3.dll), and into libmingw32.a, (which will always be statically linked); this also implies that libmingwex-3.dll must be deployed in conjunction with updated libmingw32.a, libmingwex.a, and libmingwex.dll.a.

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.

2020-05-27 18:04 Updated by: rosasmje
  • File Clipboard03.png (File ID: 5637) is attached
2020-05-27 18:05 Updated by: rosasmje
  • File Clipboard03.png (File ID: 5637) is deleted
2020-05-27 18:05 Updated by: rosasmje
Commentaire

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!!??

(Edited, 2020-05-27 18:07 Updated by: rosasmje)
2020-05-27 19:54 Updated by: cstrauss
Commentaire

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

2020-05-27 19:57 Updated by: keith
Commentaire

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.

2020-05-28 02:47 Updated by: rosasmje
Commentaire

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?!

2020-05-30 01:14 Updated by: keith
Commentaire

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.

2020-05-30 01:22 Updated by: keith
  • État Update from Ouvert to Atteints
  • Résolution Update from Aucun to Fixed
  • Composant Update from (Aucun) to WSL
Commentaire

Should be fixed, in wsl-5.3.2. Dependent applications should be relinked, with updated libraries.

2020-05-31 00:44 Updated by: rosasmje
Commentaire

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?

(Edited, 2020-05-31 00:45 Updated by: rosasmje)
2020-05-31 06:20 Updated by: keith
Commentaire

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).

2020-05-31 19:04 Updated by: rosasmje
Commentaire

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

2020-05-31 20:15 Updated by: keith
Commentaire

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.

2020-06-02 05:57 Updated by: rosasmje
Commentaire

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"

2020-06-02 06:20 Updated by: keith
Commentaire

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.

2020-06-02 17:27 Updated by: rosasmje
Commentaire

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.

2020-06-04 06:35 Updated by: keith
Commentaire

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.

Attachment File List

Modifier

Please login to add comment to this ticket » Connexion