gollvm: build failed, on FreeBSD 13.0 x86_64 #42282
Comments
|
It looks as though cmake is trying to detect whether "mmap" is present/usable, however when it tries to link a small program that uses mmap, it gets: Looks as though the compiler on this system accepts "-fsplit-stack", but the runtime library support is not there... this is not something currently handled in the cmake config setup. |
|
I think there is something broken at very base level in this environment. For instance, complains about strnlen() indicate that it is broken compilation environment, not that strnlen is missed (the function is there). Same for many other checks in the log. I think for start the detailed log with compiler output from the failing tests, and test snippets itself, should be examined. If you provide these data, I can help with interpreting the causes. The one case that obviously does not fall into this category is the check for epoll(2). FreeBSD does not have epoll, we provide kqueue. If you need epoll, there are compat shims in devel/libepoll-shim. It should be fine to have it as a dependency for gollvm. |
|
@kostikbel , thanks: appreciating your involvement. @ianlancetaylor , where there any attempts to port libgo natively (on/to FreeBSD)? |
|
@kostikbel , what is the best way to prepare/provide FreeBSD's headers? |
Prepare for what ? Provide in what sense ? |
@mneumann, do you have any experience with this. |
|
I doubt that libgo will work on FreeBSD out of the box today. |
|
System headers are always installed in /usr/include. You get them after installing base. If you are asking about non-base headers, coming from the ports/packages, and installed in /usr/local/include, of course you need to have corresponding package installed. But this is tautology. |
|
I see this
I have wiped out my VM - and installed FreeBSD 13.0 x86_64 from stratch. |
|
I am wrong: it is the same even with
|
|
This
isn't helping. |
|
This error (undef __morestack) is due to use of -fsplit-stack, as explained above. FreeBSD does not have runtime support for it, configuration should not use the flag despite compiler itself accept it. |
|
Referencing kqueue's usage: That's strange: some files have kqueue referenced only inside comments, but not within any source code. |
|
@benesch , could you validate this? |
|
CC'ing @Allenxuxu , since he has some end-user experience with both kqueue and epoll (within https://github.com/Allenxuxu/gev project ). |
|
@thanm, is this summary complete for patching CMake's config. file? |
You're in a better position to determine that than I am. |
|
@tcberner , CC'ing to you - you seem to contribute into https://www.freshports.org/devel/cmake |
heschi
added
the
NeedsInvestigation
Hi.
I was investigating current blocking issues, on FreeBSD 13.0.
And then some problems arrived:
. Then it went pretty fine:
.
The following source file isn't critical, really:
.
And then:
.
I am not using MacOS - so not sure why would CMake find this source file:
.
Let's continue:
.
This source file appears to be pretty much MacOS related -and that is not what we require, for our use case:
.
Some threading related stuff followed:
.
The next header is related to a performance monitoring framework:
. @ianlancetaylor , did anyone tried to monitor performance of Golang applications, using perfmon2?
.
.
Now some FreeBSD specific (predictive failures) arriving:
.
I am not an expert in FreeBSD - so some comments are welcome.
.
I was not able to verify if this source file has to be involved:
.
.
Here is a mission feature - and some links/explanation on FreeBSD's backtracing support would be of help:
.
I suspect that I haven't installed (via "pkg" tool? threw a corresponding BSD "port"?) libexecinfo package/dependency.
But no - it was found (thus do not understand why the header, referenced above, wasn't found):
.
Not sure that the following headers are required, in our case (look like it is related to the file I/O):
.
.
Now, a critical issue (FreeBSD vs Linux, for sure):
This looks pretty critical:
.
. Now, the following looks super obvious - simply ignoring:
.
.
Now, here is some significant information:
.
Some explanation would be much appreciated, on this:
.
.
Is the following function being a purely MacOS specific one?
.
I was trying to avoid passing too many CMake's flags (just to track down the "default" influence) - but non-needed back-ends could stripped down by -DLLVM_TARGET_TO_BUILD flag:
.
Now, significant errors arriving:
As a result - we are getting the following:
This issue is a reason for a discussion:
.
Either these are not a BSD compatible functions - or Clang can't find those (hence that I have provided 3rd party path, to search for headers - FreeBSD's repo was cloned, into another folder):
All that results into
and
.
As for the following
I would suggest some relation here.
Here is the link to this log, in case you would wish to reference it, among any other people.
My compressed build folder could be downloaded here .
The text was updated successfully, but these errors were encountered: