-
Notifications
You must be signed in to change notification settings - Fork 70
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
Software not building #62
Comments
GCC 10 uses Reference: https://gcc.gnu.org/gcc-10/porting_to.html |
Hi @thasti , I tried to compile on my raspberry Pi3 "bullseye" distro with -fno_common, but I got this result: Any other suggestion? |
Hi, I fixed it with 'make CFLAGS="-fcommon -O2" ' |
Yeah, something about the tool chain has changed in the last few years so the build config is badly broken. I'm planning on jettisoning autoconf and going to a much simpler static Makefile based build system, because I'm not supporting all the optional code blocks for reducing binary size like Igate support anymore and not willing to entertain supporting any platforms which fail autoconf tests for a functional libc. |
I'm not entirely convinced yet autoconf is the issue here (at least in the scope of the build issues reported above): From what I could make sense of back in the day, the new default in GCC 10 only exposed the presence of a number of improperly declared global symbols (see the link I posted above). To me, these pointed more to deficiencies in the code than in the build system. Back then, I was simply too lazy to fix up all these issues in the code and instead went for |
The legacy autoconf system is too complicated for me to be willing to try and figure out what the actual underlying issue is on this build failure; I've been tolerating it as well. And I don't see any portability advantages using autoconf since it isn't the 1980s anymore. I would rather just write unconditionally portable code. |
Confirming that the build fails as above on Fedora 35 and the problem is resolved by using |
I fixed this by adding the keyword "extern" to the global variables aprsis_thread and pthr_attrs in aprx.h ... there's another example of this in netresolver.c once you get further in the build; it seems like a misunderstanding about the difference between defining and declaring variables. I'm not sure I understand why it's a global variable anyway, it doesn't get used in any other C file than aprsis.c so you can probably just remove it from the header file. This is on Ubuntu using gcc 11.4.0 under Ubuntu 22.0.4 ... it appears the compiler has gotten more strict about this kind of thing. |
Hi,
is this software still under development/support?
I have got the following build error:
GCC:
Is there a possible solution?
Thanks!
The text was updated successfully, but these errors were encountered: