Incidencia #40438

Bug in libmingwex-5.3.1 dll

Abrir Fecha: 2020-05-23 18:07 Última actualización: 2020-05-27 05:56

Informador:
Propietario:
Tipo:
Estado:
Open [Owner assigned]
Componente:
(Ninguno)
Hito:
(Ninguno)
Prioridad:
2
Gravedad:
5 - Medium
Resolución:
Ninguno
Fichero:
Ninguno
Vote
Score: 0
No votes
0.0% (0/0)
0.0% (0/0)

Details

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/11 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
  • Prioridad Update from 8 to 2
  • Details Updated
Comentario

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
Comentario

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
Comentario

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
Comentario

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
Comentario

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
Comentario

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

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

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
Comentario

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
Comentario

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
Comentario

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.

Attachment File List

No attachments

Editar

Please login to add comment to this ticket » Entrar