Implementing a less memory intensive read function

[EmmaJaneBonestell]

When building the ocaml bibindings for Z3, it attempts to allocate ~10GiB before an oom error. This exceedingly high memory usage occurs while reading the import library (libz3.dll.a), and before the actual linker is called.

I don't know if there's a more efficient way to store these strings, or if it's possible to implement it such as to save results to disk and continue reading if memory usage is becoming too high. It seems very improbable that 33 GiB of strings are needed to make ~500KiB to 1.3MiB libraries.

The most pertinent information from the ctf is likely:

1391 samples of 10.4 GB allocations

 5.9 GB (57.0%) at Stdlib__Bytes.sub (bytes.ml:68:12-22, 68:12-22)
      including:
     2.9 GB via Coff.Lib.read_lib.read_member (97% of this)

 4.4 GB (42.4%) at Stdlib__Buffer.resize (buffer.ml:87:19-40)
      including:
     4.1 GB via Coff.Lib.read_lib.obj (56% of this)
     4.1 GB via Stdlib__Printf.ksprintf.k' (93% of this)
     4.1 GB via CamlinternalFormat.strput_acc (93% of this)
     4.1 GB via Stdlib__Buffer.add_string (93% of this)

The CTF is here, if you'd like to view it, though. https://gist.github.com/EmmaJaneBonestell/98fda00c93a8d09ea09bada08972761d

Edit: I used a GCP server, and it took about 33 GiB of RAM and a total of 46 GiB of allocations to build.

Edit 2: UCRT had nothing to do with it, but rather, it seems to have the excessive memory usage with any of the MSYS2 environments' built dlls. If the dll is built with Cygwin's MinGW toolchain, rather than MSYS2's MINGW toolchain, it doesn't have a problem. E.g. libz3.dll.a built with Cygwin's MinGW, vs MSYS2's, won't consume excessive RAM.

[dra27]

Sorry for taking so long to get to this - is it possible to have a complete repro case for this? flexlink is creaking somewhat with more recent Windows link libraries as well (a significant amount of the time flexlink spends appears to be parsing the CRT and Windows .a files).

[NielsMommen]

I'm experiencing similar issues when trying to build OCaml bindings for z3 on cygwin (64 bit) with mingw64-x86_64 or mingw64-i686. The build fails with error: ** Fatal error: Error while reading libz3.dll.a: Out of memory. It works on my personal machine (16GB RAM) without any errors, but allocates over 40GB of heap memory.

Repro case

I made a minimal repro case at z3-ocaml-build. It is best to use it on a windows virtual machine that has limited amount of RAM and swap space or on Github Actions (The repository contains a workflow). I will refer to the root of the repository as z3-ocaml-build_dir.

Build

The repository contains a build.ps1 script that automates the compilation of z3 and all dependencies. Run this script as follows in powershell:

powershell.exe -ExecutionPolicy RemoteSigned -File .\build.ps1

This script does the following:

1. Install cygwin with the required packages in z3-ocaml-build_dir/cygwin:
   • coreutils
   • make
   • mingw64-x86_64-gcc-g++
   • mingw64-x86_64-gmp
   • curl
   • python
2. Build following packages in z3-ocaml-build_dir/prefix using the Makefile:
   • OCaml 4.14.0
   • Flexdll 0.41
   • Findlib 1.9.1
   • Zarith 1.12
   • Z3 4.11.2 The z3 build will fail at:

     ocamlmklib -o api/ml/z3ml  -I api/ml -L. api/ml/z3native_stubs.o api/ml/z3enums.cmo api/ml/z3native.cmo api/ml/z3.cmo  -lz3 -lstdc++ -cclib -static-libgcc -cclib -static-libstdc++ -ccopt -L$(ocamlfind printconf destdir)/stublibs -dllpath $(ocamlfind printconf destdir)/stublibs

     ** Fatal error: Error while reading libz3.dll.a: Out of memory

     Inspecting the error

     We can execute the failing command in a more vebose way as follows:

3. Go to the bin directory of cygwin at z3-ocaml-build_dir/cygwin/bin and open bash.exe
4. Inside bash, cd to z3-ocaml-build_dir:

   cd /cygdrive/c/z3-ocaml-build_dir

5. Inside bash, add z3-ocaml-build_dir/cygwin/bin and z3-ocaml-build_dir/prefix/bin to PATH:

   export PATH=$PWD/prefix/bin:$PWD/cygwin/bin:$PATH

6. Inside bash, cd to prefix/z3-z3-4.11.2/build:

   cd prefix/z3-z3-4.11.2/build

We can now run the command with the verbose flag and OCAMLRUNPARAM=v4,1024 to output GC statistics :

OCAMLRUNPARAM="v=4,1024"  ocamlmklib -verbose -o api/ml/z3ml  -I api/ml -L. api/ml/z3native_stubs.o api/ml/z3enums.cmo api/ml/z3native.cmo api/ml/z3.cmo  -lz3 -lstdc++ -cclib -static-libgcc -cclib -static-libstdc++ -ccopt -L$(ocamlfind printconf destdir)/stublibs -dllpath $(ocamlfind printconf destdir)/stublibs

Which produces following output on my virtual machine with 4GB of RAM:

flexlink -chain mingw64 -stack 33554432  -o api/ml\dllz3ml.dll api/ml/z3native_stubs.o    -L. -lz3 -lstdc++ -LC:/z3-ocaml-build_dir/prefix/lib/ocaml\flexdll
allocated_words: 1242910463
minor_words: 4503709
promoted_words: 1719120
major_words: 1240125874
minor_collections: 3967
major_collections: 22
heap_words: 954046976
heap_chunks: 54
top_heap_words: 954046976
compactions: 0
forced_major_collections: 0
allocated_words: 3936
minor_words: 3936
promoted_words: 0
major_words: 0
minor_collections: 0
major_collections: 0
heap_words: 126976
heap_chunks: 1
top_heap_words: 126976
compactions: 0
forced_major_collections: 0
Growing heap to 1472k bytes
Growing heap to 1952k bytes
Growing heap to 3600k bytes
Growing heap to 5856k bytes
...
Growing heap to 4900788k bytes
Growing heap to 5635908k bytes
Growing heap to 6481296k bytes
No room for growing heap
** Fatal error: Error while reading libz3.dll.a: Out of memory

Some notes

• I tried this with several configurations that all failed:
  • Different versions of z3
  • OCaml 4.13 and 4.14
  • cygwin x86_64 and x64
  • mingw x86_64 and i686

• I still have an old cygwin installation available where the build does succeed. This cygwin installation has following packages installed:

  Packages

  _autorebase 001007-1 OK alternatives 1.3.30c-10 OK base-cygwin 3.8-1 OK base-files 4.3-3 OK bash 4.4.12-3 OK binutils 2.37-1 OK bzip2 1.0.8-1 OK ca-certificates 2.40-1 OK coreutils 8.26-2 OK crypto-policies 20190218-1 OK curl 7.78.0-1 OK cygutils 1.4.16-6 OK cygutils-extra 1.4.16-6 OK cygwin 3.2.0-1 OK dash [0.5.11.5](https://l.facebook.com/l.php?u=http%3A%2F%2F0.5.11.5%2F%3Ffbclid%3DIwAR1ZTs6Y4LfB2LbUxeIMFbEkRreyts01t21pINmfijJ5JQa0sBYf99ucoxA&h=AT3to8wjZ214esG0LxdFsucRd5YtwO0MJ4DsVrypFBGenXyxwOwggatAqP85gT6gIBwU-KUwJ2ZqRydrDqnArSrHrn0HwzGSA6t3aYW7W8uqp6ThwOPahHNdP84S4TWj4AWT_JkBOtguwBSaa5p_N0dRwxI)-1 OK diffutils 3.8-1 OK editrights 1.03-1 OK file 5.39-1 OK findutils 4.8.0-1 OK gawk 5.1.0-1 OK getent 2.18.90-4 OK gnupg 1.4.23-1 OK grep 3.7-2 OK groff 1.22.4-1 OK gzip 1.11-1 OK hostname 3.13-1 OK info 6.8-2 OK ipc-utils 1.0-1 OK less 581.2-2 OK libargp 20110921-3 OK libassuan0 2.5.3-1 OK libattr1 2.4.48-2 OK libblkid1 2.33.1-2 OK libbrotlicommon1 1.0.9-2 OK libbrotlidec1 1.0.9-2 OK libbz2_1 1.0.8-1 OK libcares2 1.14.0-1 OK libcom_err2 1.44.5-1 OK libcrypt2 4.4.20-1 OK libcurl4 7.78.0-1 OK libdb5.3 5.3.28-2 OK libexpat1 2.4.1-1 OK libfdisk1 2.33.1-2 OK libffi6 3.2.1-1 OK libgc1 8.0.4-1 OK libgcc1 11.2.0-1 OK libgcrypt20 1.8.2-1 OK libgdbm6 1.18.1-1 OK libgdbm_compat4 1.18.1-1 OK libgmp10 6.2.1-2 OK libgnutls30 3.6.9-1 OK libgpg-error0 1.37-1 OK libgpgme11 1.9.0-1 OK libgsasl-common 1.8.0-4 OK libgsasl7 1.8.0-4 OK libgssapi_krb5_2 1.15.2-2 OK libguile2.2_1 2.2.7-1 OK libhogweed4 3.4.1-1 OK libiconv2 1.16-2 OK libidn11 1.33-1 OK libidn2_0 2.3.2-1 OK libintl8 0.21-1 OK libisl23 0.24-2 OK libk5crypto3 1.15.2-2 OK libkrb5_3 1.15.2-2 OK libkrb5support0 1.15.2-2 OK libltdl7 2.4.6-7 OK liblz4_1 1.7.5-1 OK liblzma5 5.2.4-1 OK libmetalink3 0.1.3-1 OK libmpc3 1.2.1-2 OK libmpfr6 4.1.0-2 OK libncursesw10 6.1-1.20190727 OK libnettle6 3.4.1-1 OK libnghttp2_14 1.44.0-1 OK libntlm0 1.4-1 OK libopenldap2_4_2 2.4.59-1 OK libopenldap2_5_0 2.5.7-1 OK libp11-kit0 0.23.20-1 OK libpcre1 8.45-1 OK libpcre2_8_0 10.37-1 OK libpipeline1 1.5.3-1 OK libpkgconf3 1.6.3-1 OK libpopt-common 1.18-1 OK libpopt0 1.18-1 OK libpsl5 0.21.1-1 OK libreadline7 8.1-2 OK libsasl2_3 2.1.27-1 OK libsigsegv2 2.10-2 OK libsmartcols1 2.33.1-2 OK libsqlite3_0 3.34.0-1 OK libssh2_1 1.10.0-1 OK libssl1.1 1.1.1f-1 OK libstdc++6 11.2.0-1 OK libtasn1_6 4.14-1 OK libunistring2 0.9.10-1 OK libuuid-devel 2.33.1-2 OK libuuid1 2.33.1-2 OK libxml2 2.9.10-2 OK libzstd1 1.5.0-1 OK login 1.13-1 OK m4 1.4.19-1 OK make 4.3-1 OK man-db 2.9.4-1 OK mingw64-i686-binutils 2.37-1 OK mingw64-i686-gcc-core 11.2.0-1 OK mingw64-i686-gcc-g++ 11.2.0-1 OK mingw64-i686-headers 9.0.0-1 OK mingw64-i686-runtime 9.0.0-1 OK mingw64-i686-windows-default-manifest 6.4-1 OK mingw64-i686-winpthreads 9.0.0-1 OK mintty 3.5.1-1 OK ncurses 6.1-1.20190727 OK openssl 1.1.1f-1 OK p11-kit 0.23.20-1 OK p11-kit-trust 0.23.20-1 OK p7zip 15.14.1-1 OK patch 2.7.4-1 OK pkg-config 1.6.3-1 OK pkgconf 1.6.3-1 OK publicsuffix-list-dafsa 20210519-1 OK python2 2.7.18-1 OK python27 2.7.18-4 OK python27-pip 20.3.3-2 OK python27-setuptools 41.2.0-1 OK rebase 4.5.0-1 OK rlwrap 0.37-1 OK rsync 3.2.3+20200903+git9f9240b-4 OK run 1.3.4-2 OK sed 4.8-1 OK tar 1.34-1 OK terminfo 6.1-1.20190727 OK terminfo-extra 6.1-1.20190727 OK tzcode 2021a-1 OK tzdata 2021a-1 OK util-linux 2.33.1-2 OK vim-minimal 8.2.0486-1 OK wget 1.21.1-1 OK which 2.20-2 OK xz 5.2.4-1 OK zlib0 1.2.11-1 OK zstd 1.5.0-1 OK

  I tried to perform a fresh install of cygwin and specify these package versions to install. However, following packages are not available anymore:

  Unavailable packages

  package: binutils version: 2.37-1 not found package: ca-certificates version: 2.40-1 not found package: curl version: 7.78.0-1 not found package: ipc-utils version: 1.0-1 not found package: less version: 581.2-2 not found package: libcurl4 version: 7.78.0-1 not found package: liblzma5 version: 5.2.4-1 not found package: libnghttp2_14 version: 1.44.0-1 not found package: libopenldap2_4_2 version: 2.4.59-1 not found package: libopenldap2_5_0 version: 2.5.7-1 not found package: libpcre2_8_0 version: 10.37-1 not found package: libssl1.1 version: 1.1.1f-1 not found package: man-db version: 2.9.4-1 not found package: mingw64-i686-binutils version: 2.37-1 not found package: mintty version: 3.5.1-1 not found package: openssl version: 1.1.1f-1 not found package: pkg-config version: 1.6.3-1 not found package: pkgconf version: 1.6.3-1 not found package: tzcode version: 2021a-1 not found package: tzdata version: 2021a-1 not found package: xz version: 5.2.4-1 not found

  I tried to install the lowest version available for these packages, which still results in a failing build. This makes me believe that mingw64-i686-binutils has changed and causes flexdll to run out of memory.

[dra27]

This is fantastic, thanks @NielsMommen!

[NielsMommen]

Note that recently cygwin x86_64 is only supported.

[NielsMommen]

After some further investigation, I found out that MinGW binutils have changed after version 2.37. Import libraries (.dll.a) generated by ld through --out-impllib seem to have a different format, causing flexdll to consume a lot of memory to allocate buffers while reading all symbols.

Working build

As mentioned before, I'm able to build OCaml bindings for z3 on my old local cygwin installation that still has mingw64-i686-binutils version 2.37. Passing the -explain flag to flexdll while reading libz3.dll.a produces following output:

Explain output

``` Symbol _Z3_add_const_interp found in libz3.dll.a(d000001.o) Symbol __imp__Z3_add_const_interp found in libz3.dll.a(d000001.o) Symbol _Z3_add_func_interp found in libz3.dll.a(d000002.o) Symbol __imp__Z3_add_func_interp found in libz3.dll.a(d000002.o) Symbol _Z3_add_rec_def found in libz3.dll.a(d000003.o) Symbol __imp__Z3_add_rec_def found in libz3.dll.a(d000003.o) Symbol _Z3_algebraic_add found in libz3.dll.a(d000004.o) Symbol __imp__Z3_algebraic_add found in libz3.dll.a(d000004.o) Symbol _Z3_algebraic_div found in libz3.dll.a(d000005.o) Symbol __imp__Z3_algebraic_div found in libz3.dll.a(d000005.o) ... ```

Failing build

ld seems to produce a different dll.a format when building z3 with a newer (>2.37) version of binutils. Passing the -explain flag to flexdll while reading libz3.dll.a produces following output (piping the output to a file results in a file > 20GB):

Explain output

``` Scanning lib libz3.dll.a Symbol _Z3_add_const_interp found in libz3.dll.a(libz3_dll_d000001.o/ ) Symbol __imp__Z3_add_const_interp found in libz3.dll.a(libz3_dll_d000001.o/ ) Symbol _Z3_add_func_interp found in libz3.dll.a(libz3_dll_d000002.o/ libz3_dll_d000001.o/ ) Symbol __imp__Z3_add_func_interp found in libz3.dll.a(libz3_dll_d000002.o/ libz3_dll_d000001.o/ ) Symbol _Z3_add_rec_def found in libz3.dll.a(libz3_dll_d000003.o/ libz3_dll_d000002.o/ libz3_dll_d000001.o/ ) Symbol __imp__Z3_add_rec_def found in libz3.dll.a(libz3_dll_d000003.o/ libz3_dll_d000002.o/ libz3_dll_d000001.o/ ) Symbol _Z3_algebraic_add found in libz3.dll.a(libz3_dll_d000004.o/ libz3_dll_d000003.o/ libz3_dll_d000002.o/ libz3_dll_d000001.o/ ) Symbol __imp__Z3_algebraic_add found in libz3.dll.a(libz3_dll_d000004.o/ libz3_dll_d000003.o/ libz3_dll_d000002.o/ libz3_dll_d000001.o/ ) Symbol _Z3_algebraic_div found in libz3.dll.a(libz3_dll_d000005.o/ libz3_dll_d000004.o/ libz3_dll_d000003.o/ libz3_dll_d000002.o/ libz3_dll_d000001.o/ ) Symbol __imp__Z3_algebraic_div found in libz3.dll.a(libz3_dll_d000005.o/ libz3_dll_d000004.o/ libz3_dll_d000003.o/ libz3_dll_d000002.o/ libz3_dll_d000001.o/ ) ... ```

The difference is that each object is prefixed by libz3dll and the objects where each symbol is found keeps on growing for each symbol. This pattern keeps repeating: one entry for the first symbol, two entries for the second, ..., n entries for the last. This explains why flexdll is using a lot of heap memory.

Debugging coff.ml

When debugging flexdll, I noticed that the branch on line 954 is taken repeatedly in coff.ml#Lib#read_member: https://github.com/ocaml/flexdll/blob/47fbd3175369af6a63dd2c1fa6d9dfcbba66bc18/coff.ml#L946-L974

objdump

objdump -t libz3.dll.a confirms that objects are prefixed with libz3dll when built with binutils >2.37:

objdump - z3 built with binutils 2.37

``` d031590.o: file format pe-i386 SYMBOL TABLE: [ 0](sec 1)(fl 0x00)(ty 0)(scl 3) (nx 0) 0x00000000 .text [ 1](sec 2)(fl 0x00)(ty 0)(scl 3) (nx 0) 0x00000000 .idata$7 [ 2](sec 3)(fl 0x00)(ty 0)(scl 3) (nx 0) 0x00000000 .idata$5 [ 3](sec 4)(fl 0x00)(ty 0)(scl 3) (nx 0) 0x00000000 .idata$4 [ 4](sec 5)(fl 0x00)(ty 0)(scl 3) (nx 0) 0x00000000 .idata$6 [ 5](sec -1)(fl 0x00)(ty 0)(scl 3) (nx 0) 0x00000001 @feat.00 [ 6](sec 1)(fl 0x00)(ty 0)(scl 2) (nx 0) 0x00000000 __ZplRK8rationali [ 7](sec 3)(fl 0x00)(ty 0)(scl 2) (nx 0) 0x00000000 __imp___ZplRK8rationali [ 8](sec 0)(fl 0x00)(ty 0)(scl 2) (nx 0) 0x00000000 __head_libz3_dll d031589.o: file format pe-i386 SYMBOL TABLE: [ 0](sec 1)(fl 0x00)(ty 0)(scl 3) (nx 0) 0x00000000 .text [ 1](sec 2)(fl 0x00)(ty 0)(scl 3) (nx 0) 0x00000000 .idata$7 [ 2](sec 3)(fl 0x00)(ty 0)(scl 3) (nx 0) 0x00000000 .idata$5 [ 3](sec 4)(fl 0x00)(ty 0)(scl 3) (nx 0) 0x00000000 .idata$4 [ 4](sec 5)(fl 0x00)(ty 0)(scl 3) (nx 0) 0x00000000 .idata$6 [ 5](sec -1)(fl 0x00)(ty 0)(scl 3) (nx 0) 0x00000001 @feat.00 [ 6](sec 1)(fl 0x00)(ty 0)(scl 2) (nx 0) 0x00000000 __ZplRK8rationalS1_ [ 7](sec 3)(fl 0x00)(ty 0)(scl 2) (nx 0) 0x00000000 __imp___ZplRK8rationalS1_ [ 8](sec 0)(fl 0x00)(ty 0)(scl 2) (nx 0) 0x00000000 __head_libz3_dll d031588.o: file format pe-i386 SYMBOL TABLE: [ 0](sec 1)(fl 0x00)(ty 0)(scl 3) (nx 0) 0x00000000 .text [ 1](sec 2)(fl 0x00)(ty 0)(scl 3) (nx 0) 0x00000000 .idata$7 [ 2](sec 3)(fl 0x00)(ty 0)(scl 3) (nx 0) 0x00000000 .idata$5 [ 3](sec 4)(fl 0x00)(ty 0)(scl 3) (nx 0) 0x00000000 .idata$4 [ 4](sec 5)(fl 0x00)(ty 0)(scl 3) (nx 0) 0x00000000 .idata$6 [ 5](sec -1)(fl 0x00)(ty 0)(scl 3) (nx 0) 0x00000001 @feat.00 [ 6](sec 1)(fl 0x00)(ty 0)(scl 2) (nx 0) 0x00000000 __ZplRK16inf_int_rationalS1_ [ 7](sec 3)(fl 0x00)(ty 0)(scl 2) (nx 0) 0x00000000 __imp___ZplRK16inf_int_rationalS1_ [ 8](sec 0)(fl 0x00)(ty 0)(scl 2) (nx 0) 0x00000000 __head_libz3_dll ... ```

objdump - z3 built with binutils >2.37

``` libz3_dll_d031590.o: file format pe-i386 SYMBOL TABLE: [ 0](sec 1)(fl 0x00)(ty 0)(scl 3) (nx 0) 0x00000000 .text [ 1](sec 2)(fl 0x00)(ty 0)(scl 3) (nx 0) 0x00000000 .idata$7 [ 2](sec 3)(fl 0x00)(ty 0)(scl 3) (nx 0) 0x00000000 .idata$5 [ 3](sec 4)(fl 0x00)(ty 0)(scl 3) (nx 0) 0x00000000 .idata$4 [ 4](sec 5)(fl 0x00)(ty 0)(scl 3) (nx 0) 0x00000000 .idata$6 [ 5](sec -1)(fl 0x00)(ty 0)(scl 3) (nx 0) 0x00000001 @feat.00 [ 6](sec 1)(fl 0x00)(ty 0)(scl 2) (nx 0) 0x00000000 __ZplRK8rationali [ 7](sec 3)(fl 0x00)(ty 0)(scl 2) (nx 0) 0x00000000 __imp___ZplRK8rationali [ 8](sec 0)(fl 0x00)(ty 0)(scl 2) (nx 0) 0x00000000 __head_libz3_dll libz3_dll_d031589.o: file format pe-i386 SYMBOL TABLE: [ 0](sec 1)(fl 0x00)(ty 0)(scl 3) (nx 0) 0x00000000 .text [ 1](sec 2)(fl 0x00)(ty 0)(scl 3) (nx 0) 0x00000000 .idata$7 [ 2](sec 3)(fl 0x00)(ty 0)(scl 3) (nx 0) 0x00000000 .idata$5 [ 3](sec 4)(fl 0x00)(ty 0)(scl 3) (nx 0) 0x00000000 .idata$4 [ 4](sec 5)(fl 0x00)(ty 0)(scl 3) (nx 0) 0x00000000 .idata$6 [ 5](sec -1)(fl 0x00)(ty 0)(scl 3) (nx 0) 0x00000001 @feat.00 [ 6](sec 1)(fl 0x00)(ty 0)(scl 2) (nx 0) 0x00000000 __ZplRK8rationalS1_ [ 7](sec 3)(fl 0x00)(ty 0)(scl 2) (nx 0) 0x00000000 __imp___ZplRK8rationalS1_ [ 8](sec 0)(fl 0x00)(ty 0)(scl 2) (nx 0) 0x00000000 __head_libz3_dll libz3_dll_d031588.o: file format pe-i386 SYMBOL TABLE: [ 0](sec 1)(fl 0x00)(ty 0)(scl 3) (nx 0) 0x00000000 .text [ 1](sec 2)(fl 0x00)(ty 0)(scl 3) (nx 0) 0x00000000 .idata$7 [ 2](sec 3)(fl 0x00)(ty 0)(scl 3) (nx 0) 0x00000000 .idata$5 [ 3](sec 4)(fl 0x00)(ty 0)(scl 3) (nx 0) 0x00000000 .idata$4 [ 4](sec 5)(fl 0x00)(ty 0)(scl 3) (nx 0) 0x00000000 .idata$6 [ 5](sec -1)(fl 0x00)(ty 0)(scl 3) (nx 0) 0x00000001 @feat.00 [ 6](sec 1)(fl 0x00)(ty 0)(scl 2) (nx 0) 0x00000000 __ZplRK16inf_int_rationalS1_ [ 7](sec 3)(fl 0x00)(ty 0)(scl 2) (nx 0) 0x00000000 __imp___ZplRK16inf_int_rationalS1_ [ 8](sec 0)(fl 0x00)(ty 0)(scl 2) (nx 0) 0x00000000 __head_libz3_dll ... ```

objdump-z3_build_binutils_2.37.txt objdump-z3_build_binutils_2.39.txt

[nojb]

Thanks for the detective work @NielsMommen! Could you upload the failing libz3.dll.a somewhere? It would help debugging this issue. Thanks!

[nojb]

Thanks for the detective work @NielsMommen! Could you upload the failing libz3.dll.a somewhere? It would help debugging this issue. Thanks!

Never mind, I was able to to obtain it. I have a tentative fix over at https://github.com/nojb/flexdll/tree/longnames_newline. Can you try it? Thanks!

[NielsMommen]

Never mind, I was able to to obtain it. I have a tentative fix over at https://github.com/nojb/flexdll/tree/longnames_newline. Can you try it? Thanks!

Works like a charm! thanks!

[nojb]

Never mind, I was able to to obtain it. I have a tentative fix over at https://github.com/nojb/flexdll/tree/longnames_newline. Can you try it? Thanks!

Works like a charm! thanks!

Thanks for the confirmation! Submitted as PR now: #117