gollvm: build fail on slackware 14.2 in tools/gollvm/libgo/runtime_sysinfo.go #26405
Labels
NeedsInvestigation
Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Milestone
Comments
|
/cc @thanm @cherrymui |
|
Thanks for reporting this; I will take a look. |
|
Change https://golang.org/cl/124375 mentions this issue: |
|
OK, I have sent a CL that should fix the macro parser issue. For the second part, not sure what the issue might be without more info. If you can post more details on the failure mode that would be helpful. Also the output of a - v run, e.g. from the top of your build area |
|
Sorry that last bit should read: |
|
The llvm source directory is at git commit 9ca09e7b2d2. The gollvm source directory is at git commit fef66b4. I usually run fish shell, but it doesn't seem to play nice with the build scripts, so this is run from bash, with This eventually errors out with: Running |
|
Thanks -- that is helpful. What's happening is that Gollvm can't seem to locate the GCC installation on your machine. There is code in the gollvm driver (modeled after similar code in clang) that examines the host system to figure out which copy of GCC to use (for things like libgcc) -- evidently that code is not working properly. If you could do one more experiment -- run "clang -c -v himom.c" and show the first part of the output for that (up until the actual tool path invocation). |
|
Sure, here's that output: |
|
Thanks. I will work on a fix. |
|
Thanks very much for your time & help. |
zchee
pushed a commit
to zchee/golang-gollvm
that referenced
this issue
Aug 22, 2018
Be more restrictive about function-style macros -- they need to be weeded out from the get-go (as opposed to indirectly as a result of uses in other macros). Updates golang/go#26405. Change-Id: Ic8548df72d71d26ffa6b65886a08b21730026e65 Reviewed-on: https://go-review.googlesource.com/124375 Reviewed-by: Cherry Zhang <cherryyz@google.com>
|
Hi, O think I got the same issue today, the build failed and it couldn't find the same libraries even they were already installed and available in the default path. I'm using Fedora 28 x86_64. I ran the build with cmake: The error : But I have them: I tried to find a way (like an environment variable) to inform cmake about them but I think there isn't an option. |
|
I've had a similar issue on Oracle Linux 7 using devtoolset-7 which puts gcc-7 in the path, but llvm-goc still detects the gcc-4 in
The latter is a hack - not a proper detection. I know clang goes to further lengths to get this right. |
seankhliao
added
the
NeedsInvestigation
|
Got the same problem as in the comment: For my system I fixed it with hard coding in file GnuTools.cpp. I replaced lines that added And also I added the line: After that build finished successfully. |
|
@alexanius Thanks for that. Would you be willing to send a patch for this? |
Well, it does not solve the problem in general but fixes build on gentoo. Also it is possible that we can remove condition for |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Please answer these questions before submitting your issue. Thanks!
What operating system and processor architecture are you using (
go env)?x86_64, slackware 14.2
What did you do?
In my build directory:
cmake -DCMAKE_BUILD_TYPE=Release -DLLVM_TARGETS_TO_BUILD="X86" -G "Unix Makefiles" ../llvm && make all -j4but as far as I can tell, it just happens on my system regardless of other options when I build x86 (use gold linker, build with other targets, etc.)What did you expect to see?
Successful build.
What did you see instead?
Those lines in
runtime_sysinfo.gocontain:A little investigation seemed to indicate these slipped through libgo/godumpspec/m{parser,tokenizer} because their bodies don't reference their parameters.
If I comment these lines out, and analogous lines in
/[my-build-path]/tools/gollvm/libgo/sysinfo.gowhen building syscall, the build errors out while building libgo_shared because ld.gold can't find__morestack,-lgcc,crt1.o, etc. This part superficially has more in common with building gccgo. My binutils use gold, so even when I don't tell CMake to use gold, eventually it gets invoked. I am still investigating this latter part, but the above const/macro stuff seemed reportable.The text was updated successfully, but these errors were encountered: