<div dir="auto"><div><br><br><div class="gmail_quote"><div dir="ltr">Le lun. 9 avr. 2018 à 00:27, Cyril Ferlicot D <<a href="mailto:cyril@ferlicot.me">cyril@ferlicot.me</a>> a écrit :<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
Le 08/04/2018 à 10:47, Nicolas Cellier a écrit :<br>
> So once again, compiling libssh2 on win64 is broken...<br>
> This library is necessary for Pharo VM.<br>
> For now it only works "thanks" (?) to the .thirdparty-cache we have on<br>
> our build slaves.<br>
><br>
> This situation prevents from integrating further work.<br>
> <a href="https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/242" rel="noreferrer noreferrer" target="_blank">https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/242</a><br>
><br>
> Compiling unixy stuff for windows (mingw) target is tough.<br>
> Esteban and I already wasted some hours on it.<br>
> But it seems that last tentative did not succeed<br>
> <a href="https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/57e68cef046c7309261d81d8ad1c45577562f16b" rel="noreferrer noreferrer" target="_blank">https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/57e68cef046c7309261d81d8ad1c45577562f16b</a><br>
><br>
> IMO, we could as well use the prebuilt cygwin libraries, rather than<br>
> trying to compile by ourselves. This would have some advantages:<br>
> - remove the necessity for build cache<br>
> - accelerate the build workers<br>
> - be up-to-date security-wise<br>
> - focus our scarce resource to more Smalltalk-related things<br>
> - leverage the work of other teams<br>
> with maybe this drawback:<br>
> - do not completely manage the exact version of every VM component<br>
><br>
<br>
Hi Nicolas,<br>
<br>
You listed the pro to use a prebuilt cygwin libraries. Could you also<br>
list the cons for people like me who do not know them?<br><br>
I suppose that if it is not currently used there must be a reason.<br>
<br>
Thank you in advance.<br><br></blockquote></div></div><div dir="auto">Hi Cyril,</div><div dir="auto">The cons I thought about is just above: less control on exact version of library used.</div><div dir="auto">I think that this is the main reason, along with 2 others:</div><div dir="auto">- symmetry with build on other platforms (Mac).</div><div dir="auto">- historically, mingw was used for building, and since it is minimalist, it does not have pre-built libraries, not even clang which was necessary for building win64, and no support for legacy directx. That's why I had to reintroduce the heavier cygwin (with mingw target, otherwise every user of Pharo would have to install cygwin!).</div><div dir="auto"><br></div><div dir="auto">A lot of incorrect configure fail to recognize a windows platform, or we failed to guess the options to pass to configure... We have a few hacks and workarounds in the Makefile.lib.extra but it is fragile, and the build cache prevents us to detect regressions immediately.</div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
> Managing every VM component also means managing the exact configuration<br>
> of the build workers (compiler version, libraries versions, etc...),<br>
> which we do not anyway.<br>
><br>
> In the meantime, if we want to fix the build, we have to understand why<br>
> the link phase fails.<br>
><br>
> CCLD <a href="http://libssh2.la" rel="noreferrer noreferrer" target="_blank">libssh2.la</a> <<a href="http://libssh2.la" rel="noreferrer noreferrer" target="_blank">http://libssh2.la</a>><br>
> /usr/lib/gcc/x86_64-w64-mingw32/6.4.0/../../../../x86_64-w64-mingw32/bin/ld:<br>
> cannot find -link<br>
><br>
> We never told to link ink, so what is going on?<br>
> Here come autotools and his very brave libtool, or should I say libcruft.<br>
> If you want to teach yourself "how to not program", then do you a favor:<br>
><br>
> cd build.win64x64/pharo.cog.spur<br>
> mvm -f<br>
> cd build/third-party/libssh2-1.7.0<br>
> less m4/lib-link.m4<br>
><br>
> Scary! and it's just a tiny part of the overall cruft.<br>
> It's clear that the production of artifacts in such conditions is<br>
> already beyond the limits of human capabilities.<br>
> An idea could be to teach bots to do it for us, but if we really teach<br>
> them to produce such cruft, then I have no great hope that we'll live in<br>
> a better world ;)<br>
><br>
> Instead of this pathetic tentative of rule the universe imperative<br>
> programming, in such case we could enter some prolog-like rules and let<br>
> a bot do the inference for us, that may scale a bit longer...<br>
><br>
> If I go into<br>
> build.win64x64/pharo.cog.spur/build/third-party/libssh2-1.7.0 and<br>
> inquire a bit, I see this:<br>
><br>
> grep -r '\-link' . | less<br>
><br>
> ./aclocal.m4:m4_include([m4/lib-link.m4])<br>
> ./compile: linker_opts="-link$linker_opts"<br>
> ./config.status:archive_cmds='$CC -o $lib $libobjs $compiler_flags<br>
> `func_echo_all "$deplibs" | $SED '\''s/ -lc$//'\''` -link -dll~linknames='<br>
> ./configure: sed -n -e 's/\\\\\\\(.*\\\\\\\)/-link\\\<br>
> -EXPORT:\\\\\\\1/' -e '1\\\!p' < $export_symbols ><br>
> $output_objdir/$soname.exp;<br>
> ./configure: sed -e 's/\\\\\\\(.*\\\\\\\)/-link\\\<br>
> -EXPORT:\\\\\\\1/' < $export_symbols > $output_objdir/$soname.exp;<br>
> ./configure: archive_cmds='$CC -o $lib $libobjs $compiler_flags<br>
> `func_echo_all "$deplibs" | $SED '\''s/ -lc$//'\''` -link -dll~linknames='<br>
> ./docs/Makefile: $(top_srcdir)/m4/lib-ld.m4<br>
> $(top_srcdir)/m4/lib-link.m4 \<br>
> ./docs/Makefile.in: $(top_srcdir)/m4/lib-ld.m4<br>
> $(top_srcdir)/m4/lib-link.m4 \<br>
> ./example/Makefile: $(top_srcdir)/m4/lib-ld.m4<br>
> $(top_srcdir)/m4/lib-link.m4 \<br>
> ./example/Makefile.in: $(top_srcdir)/m4/lib-ld.m4<br>
> $(top_srcdir)/m4/lib-link.m4 \<br>
> ./libtool:archive_cmds="\$CC -o \$lib \$libobjs \$compiler_flags<br>
> \\\`func_echo_all \\\"\$deplibs\\\" | \$SED 's/ -lc\$//'\\\` -link<br>
> -dll~linknames="<br>
> ./libtool: # -O*, -flto*, -fwhopr*, -fuse-linker-plugin GCC<br>
> link-time optimization<br>
> ./libtool: -O*|-flto*|-fwhopr*|-fuse-linker-plugin)<br>
> ./ltmain.sh: # -O*, -flto*, -fwhopr*, -fuse-linker-plugin GCC<br>
> link-time optimization<br>
> ./ltmain.sh: -O*|-flto*|-fwhopr*|-fuse-linker-plugin)<br>
> ./m4/lib-link.m4:# lib-link.m4 serial 13 (gettext-0.16.2)<br>
> ./m4/libtool.m4: sed -n -e 's/\\\\\\\(.*\\\\\\\)/-link\\\<br>
> -EXPORT:\\\\\\\1/' -e '1\\\!p' < $export_symbols ><br>
> $output_objdir/$soname.exp;<br>
> ./m4/libtool.m4: sed -e 's/\\\\\\\(.*\\\\\\\)/-link\\\<br>
> -EXPORT:\\\\\\\1/' < $export_symbols > $output_objdir/$soname.exp;<br>
> ./m4/libtool.m4: _LT_TAGVAR(archive_cmds, $1)='$CC -o $lib<br>
> $libobjs $compiler_flags `func_echo_all "$deplibs" | $SED '\''s/<br>
> -lc$//'\''` -link -dll~linknames='<br>
> ./m4/libtool.m4: $SED -n -e 's/\\\\\\\(.*\\\\\\\)/-link\\\<br>
> -EXPORT:\\\\\\\1/' -e '1\\\!p' < $export_symbols ><br>
> $output_objdir/$soname.exp;<br>
> ./m4/libtool.m4: $SED -e 's/\\\\\\\(.*\\\\\\\)/-link\\\<br>
> -EXPORT:\\\\\\\1/' < $export_symbols > $output_objdir/$soname.exp;<br>
> ./m4/libtool.m4:*\ -fuse-linker-plugin*\ *) CFLAGS="$CFLAGS<br>
> -fno-use-linker-plugin" ;;<br>
> ./Makefile: $(top_srcdir)/m4/lib-ld.m4 $(top_srcdir)/m4/lib-link.m4 \<br>
> ./Makefile: ! -type d ! -perm -444 -links 1 -exec chmod a+r {} \; -o \<br>
> ./Makefile.in: $(top_srcdir)/m4/lib-ld.m4 $(top_srcdir)/m4/lib-link.m4 \<br>
> ./Makefile.in: ! -type d ! -perm -444 -links 1 -exec chmod a+r {} \; -o \<br>
> ./src/CMakeLists.txt: # Fall back to over-linking dependencies<br>
> ./src/Makefile: $(top_srcdir)/m4/lib-ld.m4 $(top_srcdir)/m4/lib-link.m4 \<br>
> ./src/Makefile.in: $(top_srcdir)/m4/lib-ld.m4<br>
> $(top_srcdir)/m4/lib-link.m4 \<br>
> ./tests/Makefile: $(top_srcdir)/m4/lib-ld.m4<br>
> $(top_srcdir)/m4/lib-link.m4 \<br>
> ./tests/Makefile.in: $(top_srcdir)/m4/lib-ld.m4<br>
> $(top_srcdir)/m4/lib-link.m4 \<br>
><br>
> Oh my, I don't even want to decipher that, it's obviously write-only.<br>
> All I understand is that the autoshit could decide to insert a -link by<br>
> itself and make our build fail at link phase in certain conditions...<br>
> It remains to see what we recently introduce to trigger these conditions.<br>
> How to debug this, I have no idea (insert prints here and there...).<br>
> Good luck.<br>
><br>
<br>
<br>
--<br>
Cyril Ferlicot<br>
<a href="https://ferlicot.fr" rel="noreferrer noreferrer" target="_blank">https://ferlicot.fr</a><br>
<br>
</blockquote></div></div></div>