flexlink produces an invalid dll when building lablgtk-2.18.3 on mingw64 #6
Comments
|
Is it easy for you to test with OCaml trunk? The win64 backend has been changed to avoid problems when the DLL is loaded too far away in memory from the main process, and this might fix such issues. |
|
I have tried the latest ocaml and camlp4 from the github mirror. The problem remains. |
|
The issue seems to be related to the cygwin64 COMDATA hacks which are introduced in commit 37e6b5a. The library works if the snippets are commented out. |
|
Perhaps the current hacks for Cygwin64 should be restricted to cygwin64 indeed. Can you check which parts in the commit you refer to must be disabled (there are two fragments related to COMDATA sections -- do we need to disable both)? |
|
Disabling the following fragment in add_reloc_table works in my case: This should be the first fragment mentioning COMDATA in the patch. |
|
As reported by Andreas Hauptmann on the caml-list:
|
|
I'm having what appears to be a related issue trying to build lablgtk 2.18.5 with flexdll 0.35 and ocaml 4.02.3 on cygwin64: ocamlmktop -I +lablGL -thread -o lablgtktop unix.cma threads.cma lablgl.cma |
|
FWIW, stripping does help on Cygwin; I was able to get a successful and functional build by adding |
|
Would it be possible to eventually fix this? This issue is hanging around for more than 2 years now. I just tried it with the source and binary delivieres version 0.35 as well as the current git master. This is a major source of build unreliabilities in the Windows builds of INRIA Coq. I currently use an explicit call to strip which magically fails as well if completely unrelated things in the build script are changed (like to which file messages are redirected). Why this is even procmon couldn't help me to understand. I will now instead try the method suggested above instead of the explicit call to strip. But I would really appreciate a fix for this problem. If there is anything I can do to help, please let me know. E.g. I can send a script which sets up a fresh cygwin and reproduces the error with a single call to a batch file. Best regards, Michael |
|
I'm afraid I don't understand the problem enough to fix it, and don't have the time and courage to investigate. If you could create a simple reproduction case that don't involve a bunch of external libraries, this would definitely make the problem easier to investigate. But the conclusion could also be that there is no easy fix. I think my recommendation would be to avoid using flexlink with code not generated by OCaml compilers. For your use case, is it an option to link all native libraries statically in the main program? |
|
Dear Alain, you are right, maybe the best option is to patch the lablgtk build scripts such that they create just a static library and use this. I think for the whole lablgtk library there is no need to link it dynamically, since the GUI tool always needs it and in Coq there is only one GUI tool, so there wouldn't be DLL sharing either. Also it is an interesting hint that the issues might come from the C code in lablgtk. I will let you know how it goes along this path. Best regards, Michael |
|
FYI this is the patch I used to work around this: https://github.com/cygwinports/ocaml-lablgtk2/blob/master/2.18.5-flexlink.patch |
|
I ran into this too, but doing my usual fumbling in the dark noticed that one of the fixes above involved reducing the number of diff --git a/reloc.ml b/reloc.ml
index 358f6b9..823021d 100644
--- a/reloc.ml
+++ b/reloc.ml
@@ -434,7 +434,7 @@ let add_reloc_table obj obj_name p =
indirection pointers to external darta symbols. Since we don't deal with such section
properly, we turn them into regular data section, thus loosing sharing (but we don't care). *)
sec.sec_opts <- 0xc0500040l;
- sec.sec_name <- Printf.sprintf ".flexrefptrsection%i" (Oo.id (object end));
+ sec.sec_name <- Printf.sprintf ".flex$.flexrefptrsection%i" (Oo.id (object end));
end;
let min = ref Int32.max_int and max = ref Int32.min_int inwhich appears to be enough to build a working lablgtk2 without having to strip the DLLs (one slight thing which concerned me with the stripping is that the resulting DLLs also crash Microsoft's objdump, though that may be objdump's fault, and it was on the Windows 7 SDK). I don't really understand @alainfrisch's comment about not dealing with the section properly - what prompted you to write that comment originally? Is this all related to #52 and should we therefore be deleting these sections for symbols which flexdll is going to relocate and simply leaving it alone for any other symbols, which presumably the linker is going to deal with. It appears on a vague inspection that the linker will eliminate these in "normal" linking, so I'm guessing they just get folded into the normal relocation process? Again, fumbling around trying to diagnose the original problem, I can't find a reference to the idea of a problem about having too many sections in the PE header (there's a reference to a limit of 96 for Windows XP but it's increased to 65536 since Vista, so that doesn't seem a likely candidate). Perhaps it's that these sections appear before one of the others and some offset becomes too big or larger than expected. Either way, stripping removes those sections and, on the basis that merging them also seems to fix the problem then it would appear to be the number of them which is the underlying issue. But it still begs the question (from me at least) of what precisely they're for and what we should really be being done with them... |
I don't remember exactly, but keeping the COMDAT section resulted in some problems with cygwin64. (Perhaps because the section could be merged by the linker, and this breaks some assumptions made by the flexdll runtime.) I don't think this was related to #52. |
* Set up CI with Azure Pipelines * Switch to azure pipelines * bump * Use shorter path
Hi all,
I'm recently building lablgtk (a GTK2 wrapper for OCaml) using mingw64 toolchains provided by msys2. The package uses ocamlmklib (and thus flexlink) to create a dll library called dlllablgtk2.dll. Here are the version of the tools in my environment:
Flexlink generates the library without error, but the library is considered invalid by LoadLibraryEx:
The following toy program gives the same result.
The library is created using 24 object files in addition to some system libraries. The command is:
When I remove some of the objects (e.g. ml_gtktree.o), the generated library becomes valid.
It seems the issue is not raised by a single object. The library built without ml_gtktext.o (but with ml_gtktree.o) is also valid.
The binaries from https://github.com/shadinger/flexdll-win64 (version 0.26) does not suffer from this issue.
Here is the verbose log during linking.
The text was updated successfully, but these errors were encountered: