Closed revelator closed 3 years ago
Technically clang32... may or may not happen on clang64 (probably does if it's what I think)
Are you by chance piping output into something (such as tee
, such as by using the --log
option to makepkg(-mingw)?). I ran into some mystery crashes related to writing output when I was doing that, that went away after I stopped. msys2/CLANG-packages#3
not while building gtk2 no :) though i do use the logging from time to time to make it easier to see where in the code it happens. this however i copied from the msys2 shell.
btw it also happens in clang64 so it is not 32 bit related.
i know clang chokes on -fPIC but i noticed a -DPIC in the compile does clang handle this ?
that's just a normal C preprocessor define. No problem.
oki then :)
heres the output from the 64 bit compile, warning wall of text incomming :S
it does look like the issue I ran into with piping through tee
though... wonder what's up with that
well i just used MINGW_ARCH=clang64 makepkg-mingw -c --skippgp --nocheck so i assumed theres no piping ?
no there shouldn't be... are you using mintty or something else that might be using cygwin ptys? I use windows terminal so start in 'normal' windows console mode. maybe try running from a normal windows console for a test?
yah i use mintty, ok ill try that.
there was an MSYS2 report lately about flaky pipes, and the pty code in cygwin dll is a hot mess
might be it lets see building via cmd this time.
sadly made no difference same error :S
I'm stumped then.... @mati865 ?
me2... looks like it is choking on some of the macro calls in glib to me though.
looking forward to building graphviz now oh joy :P
Seems like preprocessor has crashed because it could not allocate more memory. Can you observe memory usage during build with 64-bit clang or tell how to reproduce it (is it enough to run makepkg)?
just running makepkg is enough, ill look out for if memory usage spikes on it.
May need more dependencies than official repos have gotten through though
not seing anything out of the ordinary with memory usage so far not really sure how to proceed ?
on a hunch i tried several older versions as well they all crash in the exact same spot, so it might actually be a gtk2 bug that noone has caught before.
I am actually not quite sure how you managed to get as far as attempting to build gtk2 so fast 😮
persistence and a good deal of patching :) mostly removing -rpath and -fPIC from dependencies that were to stubborn to build.
would make it easier going forward if the offending flags were just ignored by the llvm toolset, one thing though --version-script needs a real fix as it is used to make linker map files and is supported even by msvc and pretty much any windows compiler out there. it does work for unix and apple though is named differently in those. -Bsymbolic might also need a real fix.
-Wl,-exported_symbols_list was the name for -Wl,--version-script but it does not work on windows unfortunatly.
list of packages i managed to build, some might be a little lobotomized like magnum-integrations and plugins plus vala though i had to disable valadoc as i couldnt build all the dependencies.
one thing though --version-script needs a real fix as it is used to make linker map files and is supported even by msvc and
Msvc doesn't support it, it uses .def
files that are supporoted by LLD.
it is called /MAP on msvc so yes it does https://docs.microsoft.com/en-us/cpp/build/reference/map-generate-mapfile?view=msvc-160
on unix it also seems to do other stuff but on windows ld basically emulates the msvc option :)
also a bit misleading and a bit phun /MAP outputs .sym files not .map files xD it does not support symbol versioning though but both flags can be used to create a list of symbols. meson allready has support for this with clang it seems.
but it would be ok if the --version-script flags just wrapped the linker commands needed as that would be a huge timesaver.
I didn't know that version script did anything other than symbol versioning, so assumed it was a no-op on Windows as Windows DLLs don't have that.
I also thought -Bsymbolic was an ELF thing. What is that expected to do on Windows?
-Bsymbolic might have been a fluke on my part sorry. msvc /MAP while it does output a symbol table is mostly used for debugging purposes on windows while on nix it is used in a bit the same way as we use a .def on windows with the exception that it also does symbol versioning. Info is a bit shoddy on both to say the least :/
still it would be nice if these flags were just ignored on windows, throwing an error seems a bit counterproductive.
possibly the best explanation i could find is here https://web.archive.org/web/20110830095842/http://www.codeproject.com/KB/debug/mapfile.aspx
Yes, I have done mapfile-based debugging in the past.
basically msvc .map files are textual representations of what we get if we run a dll thorugh depends so good for debugging :)
nix .map looks a little different
5975: symbol=_ZN9SpaceshipC1ERKSs; lookup in file=./testflight
5975: symbol=_ZN9SpaceshipC1ERKSs; lookup in file=./libspaceship.so.1
5975: symbol=_ZN9Spaceship19stabiliseIonFluxersEv; lookup in file=./testflight
5975: symbol=_ZN9Spaceship19stabiliseIonFluxersEv; lookup in file=./libspaceship.so.1
but both can basically be used for the same thing though the nix variant has a few more tricks than the msvc version.
I think the most common use for --version-script
on Windows is for selecting which symbols to export (MVSC does it by using .def
file which is supported by both BFD and LLD).
Haven't yet faced map files so cannot tell about them.
Supporting version scripts in LLD's COFF backend would be very welcome but it's a lot of work since you'd have start from scratch.
@revelator Please use any online paste tool like PasteBin or GitHub Gist or others for the long output logs.
aye, and porting the functionality from binutils ld would also mean porting C to C++ :S. @Biswa will do.
aye, and porting the functionality from binutils ld would also mean porting C to C++ :S.
You cannot just copy the code and adjust it because of the Binutils license.
@revelator Please use any online paste tool like PasteBin or GitHub Gist or others for the long output logs.
I have had good success with <summary>
/<details>
collapsible sections in the past, but yeah, something external would be better for something very long.
@mati865 ah true well then it is the hard way i reckon. @jeremyd2019 pastebin is ok by me :) luckily i did not post the entire log or we would still be reading xD
still it would be nice if these flags were just ignored on windows, throwing an error seems a bit counterproductive.
My notes from msys2-autobuild failures is up to 17 packages that obviously failed due to -fPIC
, not counting any that have already been fixed to not do that anymore.
does not sound like overly much still a few other packages choke on stuff other than -fPIC :/ -Wl,-rpath for one though oddly the compiler accepts just -rpath or is that a libtool flag ?.
also i noticed gtk2 and a few others that fail are actually running tee by themself, so seems there is indeed something screwy going on with that.
`#!/bin/bash
tee "$@" > /dev/null`
just a test
try using ``` to block off your code
https://docs.github.com/en/github/writing-on-github/creating-and-highlighting-code-blocks
Yeah sometimes the code blocks need more ``` i noticed :S well the above code piece did not fix gtk2 but it did allow me to filter out where it goes wrong, in the ifs code in clang it crashes when trying to create stubs.
well this is kinda odd add -Wno-expansion-to-defined to the preprocessor flags and gtk2 gets a lot farther. unfortunatly it fails on the final link with this error ->
llvm-rc: Error in RT_MANIFEST statement (ID CREATEPROCESS_MANIFEST_RESOURCE_ID):
error : file not found : gtk
i686-w64-mingw32-windres: error: llvm-rc failed```
also make -j1 or things go boom.
looks like llvm-rc does not like manifests since it looks an awfull lot like an xml parser error.
any idea what might cause this ?