-
Notifications
You must be signed in to change notification settings - Fork 63
1.0 RC: build failure on ARM 32 bit #677
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
Hi @olebole , hmmm looks like an aftermath of the source-splitting edition of datatypes.cpp that was so huge it would take forever to compile. Strange that this does not pass on the arm when it's ok on all the other platforms. Indeed, 9 other source files (basic_op.cpp, ifmt.cpp, ofmt.cpp, defaul_io.cpp, basic_op_mult.cpp, basic_op_div.cpp,basic_op_add.cpp, basic_op_sub.cpp,basic_op_new.cpp) 'refine' the basic GDL objects (Bytes, Ints etc). I suppose the arm compiler does not like to see the objects "augmented" in a separate file but certainly there should be a compiler option to do that? Of course there is always a solution by including these .cpp files as includes in datatypes.cpp, provided a lot of #ifdefs all over the place... |
Seeing the same on Fedora - https://kojipkgs.fedoraproject.org//work/tasks/4157/41324157/build.log |
This happens with 1.0.o~rc2 as well. |
I do not see any way out except reverting to the earlier version where the compilation time was x 4. |
@GillesDuvert (from #761 (comment))
The software environment is basically the same on armhf as on the other platforms (amd64, arm64, i386 etc.). Specifically, I compared the output of cmake between armhf and arm64, without any differences. The C compiler is of version 9.3.0:
|
I am hitting that bug too, and this is not a new story. More details can be found here: The short story is: C++ standards are violated and we get what we deserved; this shows up only on ARM v7 because the ABI is stricter for various reasons that you can find in the mame thread. The fix is to do it the long way, instantiate only once the symbol... |
To give an update here: this remains a problem with version 1.0.0, on ARM 32 bit. It works on ARM 64 bit and on x86 32 bit. |
Another Debian Developer (@AdrianBunk) just proposed as a workaround to add |
I love you olebole, and send my kisses to AdrianBunk :) That works perfectly. Thanks! |
Would it then make sense to add it to GDL CMake default linker flags? |
As a workaround on ARM, this would probably be useful. |
Adding it (for the linkers that support it (?)) seems necessary. The symbols 'code' are repeated in the different .o files, but it is the same code, so no risk. |
Did somebody do it? |
@GillesDuvert you mean whether somebody tested it? I already uploaded a gnudatalanguage package to Debian with that change, and it compiled. |
I meant, add |
On Debian's "armhf"/"armel" platforms (ARM processor, 32 bit), I get the following build error when linking the shared library, which looks a bit mystic to me:
Full build log here. I have no idea what this is about.
The text was updated successfully, but these errors were encountered: