<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On 8 April 2018 at 18:48, Eliot Miranda <span dir="ltr"><<a href="mailto:eliot.miranda@gmail.com" target="_blank">eliot.miranda@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> <br><div dir="auto"><div>Hi Nicolas, Hi Esteban,<br><br></div><div><br>On Apr 8, 2018, at 1:47 AM, Nicolas Cellier <<a href="mailto:nicolas.cellier.aka.nice@gmail.com" target="_blank">nicolas.cellier.aka.nice@<wbr>gmail.com</a>> wrote:<br><br></div><blockquote type="cite"><div><span></span></div></blockquote><blockquote type="cite"><div><div dir="ltr"><div><div><div><div><div><div><div><div><div><div><div>So once again, compiling libssh2 on win64 is broken...<br></div>This library is necessary for Pharo VM.<br></div><div>For now it only works "thanks" (?) to the .thirdparty-cache we have on our build slaves.<br><br></div><div>This situation prevents from integrating further work.<br><a href="https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/242" target="_blank">https://github.com/<wbr>OpenSmalltalk/opensmalltalk-<wbr>vm/pull/242</a><br><br></div><div>Compiling unixy stuff for windows (mingw) target is tough.<br></div><div>Esteban and I already wasted some hours on it.<br></div><div>But it seems that last tentative did not succeed<br><a href="https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/57e68cef046c7309261d81d8ad1c45577562f16b" target="_blank">https://github.com/<wbr>OpenSmalltalk/opensmalltalk-<wbr>vm/commit/<wbr>57e68cef046c7309261d81d8ad1c45<wbr>577562f16b</a><br><br></div>IMO, we could as well use the prebuilt cygwin libraries, rather than trying to compile by ourselves. This would have some advantages:<br></div>- remove the necessity for build cache<br></div>- accelerate the build workers<br></div>- be up-to-date security-wise<br></div><div>- focus our scarce resource to more Smalltalk-related things<br></div><div>- leverage the work of other teams<br></div>with maybe this drawback:<br></div>- do not completely manage the exact version of every VM component<br></div></div></div></div></div></div></blockquote><div><br></div>Seems like a really good idea to me.  Why build anything that one's chosen platform provides anyway?<div><br><blockquote type="cite"><div><div dir="ltr"><div><div><div><div><br></div>Managing every VM component also means managing the exact configuration of the build workers (compiler version, libraries versions, etc...), which we do not anyway.<br><br></div>In the meantime, if we want to fix the build, we have to understand why the link phase fails.<br><br>CCLD     <a href="http://libssh2.la" target="_blank">libssh2.la</a><br>
/usr/lib/gcc/x86_64-w64-<wbr>mingw32/6.4.0/../../../../x86_<wbr>64-w64-mingw32/bin/ld: cannot find -link<br></div></div></div></div></blockquote><div><br></div>Presumably the makefile is written to use the compiler as the linker and to pass linker-specific commands to the real linker via -link.  If one is going to use ld (i.e. the real linker) directly then one doesn't need -link.  Right?</div></div></blockquote><div><br></div><div>I think my brain's natural pattern matching has been faulty.   </div><div>All the other posts I've been reading this as "dash  LINK"</div><div>but like a stereoscopic <span style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:small;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">3D<span> shark images suddenly coming into focus,</span></span></div><div>I'm suddenly reading it as  "dash  L  INK"</div><div><br></div><div>Is it missing an "ink" library?</div><div><br></div><div>Similar to this...</div><div><a href="https://tinyurl.com/mingw32-ld-cannot-find">https://tinyurl.com/mingw32-ld-cannot-find</a><br></div><div><br></div><div>cheers -ben</div><div><br></div><div><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto"><div><br><blockquote type="cite"><div><div dir="ltr"><div><div><br></div><div>We never told to link ink, so what is going on?<br></div><div>Here come autotools and his very brave libtool, or should I say libcruft.<br></div><div>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.<wbr>0<br>    less m4/lib-link.m4<br><br></div><div>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 already beyond the limits of human capabilities.<br></div><div>An idea could be to teach bots to do it for us, but if we really teach them to produce such cruft, then I have no great hope that we'll live in a better world ;)<br></div><div><br>Instead of this pathetic tentative of rule the universe imperative programming, in such case we could enter some prolog-like rules and let a bot do the inference for us, that may scale a bit longer...</div><div><br></div>If I go into build.win64x64/pharo.cog.spur/<wbr>build/third-party/libssh2-1.7.<wbr>0 and inquire a bit, I see this:<br><br>    grep -r '\-link' . | less<br><br><span style="font-family:monospace,monospace">./aclocal.m4:m4_include([m4/<wbr>lib-link.m4])<br>./compile:    linker_opts="-link$linker_<wbr>opts"<br>./config.status:archive_cmds='<wbr>$CC -o $lib $libobjs $compiler_flags `func_echo_all "$deplibs" | $SED '\''s/ -lc$//'\''` -link -dll~linknames='<br>./configure:        sed -n -e 's/\\\\\\\(.*\\\\\\\)/-link\\\ -EXPORT:\\\\\\\1/' -e '1\\\!p' < $export_symbols > $output_objdir/$soname.exp;<br>./configure:        sed -e 's/\\\\\\\(.*\\\\\\\)/-link\\\ -EXPORT:\\\\\\\1/' < $export_symbols > $output_objdir/$soname.exp;<br>./configure:    archive_cmds='$CC -o $lib $libobjs $compiler_flags `func_echo_all "$deplibs" | $SED '\''s/ -lc$//'\''` -link -dll~linknames='<br>./docs/Makefile:        $(top_srcdir)/m4/lib-ld.m4 $(top_srcdir)/m4/lib-link.m4 \<br>./docs/Makefile.in:     $(top_srcdir)/m4/lib-ld.m4 $(top_srcdir)/m4/lib-link.m4 \<br>./example/Makefile:     $(top_srcdir)/m4/lib-ld.m4 $(top_srcdir)/m4/lib-link.m4 \<br>./example/Makefile.in:  $(top_srcdir)/m4/lib-ld.m4 $(top_srcdir)/m4/lib-link.m4 \<br>./libtool:archive_cmds="\$CC -o \$lib \$libobjs \$compiler_flags \\\`func_echo_all \\\"\$deplibs\\\" | \$SED 's/ -lc\$//'\\\` -link -dll~linknames="<br>./libtool:      # -O*, -flto*, -fwhopr*, -fuse-linker-plugin GCC link-time optimization<br>./libtool:      -O*|-flto*|-fwhopr*|-fuse-<wbr>linker-plugin)<br>./ltmain.sh:      # -O*, -flto*, -fwhopr*, -fuse-linker-plugin GCC link-time optimization<br>./ltmain.sh:      -O*|-flto*|-fwhopr*|-fuse-<wbr>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\\\ -EXPORT:\\\\\\\1/' -e '1\\\!p' < $export_symbols > $output_objdir/$soname.exp;<br>./m4/libtool.m4:            sed -e 's/\\\\\\\(.*\\\\\\\)/-link\\\ -EXPORT:\\\\\\\1/' < $export_symbols > $output_objdir/$soname.exp;<br>./m4/libtool.m4:        _LT_TAGVAR(archive_cmds, $1)='$CC -o $lib $libobjs $compiler_flags `func_echo_all "$deplibs" | $SED '\''s/ -lc$//'\''` -link -dll~linknames='<br>./m4/libtool.m4:              $SED -n -e 's/\\\\\\\(.*\\\\\\\)/-link\\\ -EXPORT:\\\\\\\1/' -e '1\\\!p' < $export_symbols > $output_objdir/$soname.exp;<br>./m4/libtool.m4:              $SED -e 's/\\\\\\\(.*\\\\\\\)/-link\\\ -EXPORT:\\\\\\\1/' < $export_symbols > $output_objdir/$soname.exp;<br>./m4/libtool.m4:*\ -fuse-linker-plugin*\ *) CFLAGS="$CFLAGS -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 $(top_srcdir)/m4/lib-link.m4 \<br>./tests/Makefile:       $(top_srcdir)/m4/lib-ld.m4 $(top_srcdir)/m4/lib-link.m4 \<br>./tests/Makefile.in:    $(top_srcdir)/m4/lib-ld.m4 $(top_srcdir)/m4/lib-link.m4 \</span><br></div></div></div></blockquote><div><br></div>ROTFL</div><div><br><blockquote type="cite"><div><div dir="ltr"><div><br></div><div>Oh my, I don't even want to decipher that, it's obviously write-only.<br></div><div>All I understand is that the autoshit could decide to insert a -link by itself and make our build fail at link phase in certain conditions...<br></div><div>It remains to see what we recently introduce to trigger these conditions.<br></div><div>How to debug this, I have no idea (insert prints here and there...).<br></div><div>Good luck.</div></div>
</div></blockquote><br></div><div>Time to stop building libssh2 (or any other library available prebuilt) on Cygwin?</div></div><br></blockquote></div><br></div></div>