Hi folks,
I’m just trying to figure out why Travis is failing my build when I build locally completely fine. You can see from here that things like printf() and other standard C/C++ code is undefined:
https://travis-ci.org/ButchDean/interactive_computer_graphics/jobs/558002721
I’m pretty sure I am missing something here but don’t know what it is.
Any help appreciated!
Thanks.
It was working before https://travis-ci.org/ButchDean/interactive_computer_graphics/jobs/556928323
What changed?
Okay, let me put it another way. Why does it build cleanly locally but not on Travis? If it had the same errors locally I would know it is because I missed a standard include.
Clearly this is likely to do with my Travis file but I don’t know what it is.
From the errors, you are clearly missing #include <cstdio>.
Typical reasons are:
It’s only likely to be the second one in building on a different environment. My branch is certainly clean and I performed clean builds to test.
So I built on old RedHat 6 and the latest Ubuntu and both build cleanly. I know for sure there is something wrong with the way I’ve written my .travis.yml file.
Anybody have any idea still?
Here’s the diff between the last successful build on master and the first failure showing this problem. The obvious difference is the use of g++-6 package from ubuntu-toolchain-r-test. I would start from there.
Yes, I changed it because the old way wasn’t working after my code changes. Now this other way isn’t working either.
I’ll try several more things later and if it still won’t work I’ll remove it from the project.
Thanks.
Why not just fix your code rather than juggling with tools to make them accept broken code?
It’s your call, of course, but don’t expect help with doing a wrong thing ('cuz it would have you come back here begging for help when it crashes on you again).
It’s standard practice to include all public headers whose functionality a source file directly uses, even if they are implicitly included from elsewhere.
If it builds locally without issue then it is Travis’ fault. I organized the code in such a way that the headers are in one place and appropriately referenced, it builds fine locally. I have seen other CI systems and currently work with them (like Jenkins) that deal with really badly organized code.
Once again, if my code builds without issue locally over multiple Linux distros then Travis should not require me to reorganize already working code to work around its deficiencies - that is not how CI works.
I do not believe this is a fair statement. The fact that your tests pass on your machine could mean that your machine contains some files necessary for the tests, whereas on the CI machines those are missing or different versions are used for whatever reason (e.g., CI doesn’t provide certain packages by default, you made local changes to your code or dependencies that don’t get reflected in CI, CI pulls down the most recent versions of your dependencies which introduces incompatibilities).
But I tried on both RedHat and Ubuntu. Sorry to seem like a dick, but I simply am not convinced, especially since nothing has been offered to look into Travis itself rather than “it’s your project structure/code changes”.
When I look at the code and see that it uses stdio function but has no #include <cstdio>, I look no further. That’s a language violation, it shouldn’t work according to the language standard. So even if it happens to work for you for some reason, it’s an unsupported use case and Travis cannot guarantee that it’ll work.
As for the possible reason, https://stackoverflow.com/questions/57033333/what-implementation-of-getenv-is-used-if-no-header-is-included suggests that in some compiler versions, code with undefined functions might compile but crash at runtime. Maybe under some circumstances, the compiler can even link such a functon to some definition (e.g. if you do include this header in some other compilation unit). If this is the case, the compiler violates (relaxes) the language standard and as such, there’s no guarantee that other compilers or even other versions of the same compiler will work the same.
That’s exactly what standards are for: if you compily, you are officially guaranteed predictable behavior, and people will be fixing things if it’s not delivered. If you don’t, no-one guarantees you anything, any result (including errors and random behavior) is possible.
This is ultimately C code and I cannot touch the actual source. I’ve been building the code with GCC7 and 8. If what you say is true then it likely should be reflected on my setup.
So I gave the benefit of doubt to you guys are also tried to be more specific with the .travis.yml script and it is still failing. Instead of using stdio.h I used cstdio on a new branch (fixingtravis).
This snippet
#include <cstdio>
int main() {
printf("hello world\n");
return 0;
}
works, and updating to g++-6 also works.
Something else in your setup is causing this problem. I don’t know enough about your code to comment much further than this.
Oh yes, I’m well aware of other code working. If you look at some other projects on my profile you will see that it works fine for those specific applications, and was working up to a point with this project. What I’m trying to get to is the ‘why’ this is happening and how to fix it.
As I said before, if I can build locally successfully every time locally then technically Travis CI should not have any issues either, which to me is a given. Imagine having a development environment for dev machines where collaborative work builds when they clone the repo and build locally, then they all make changes and merge them locally and everything still goes well. Now, they push this merged code that builds up to the CI environment and it breaks, clearly this is to do with either the CI environment being specifically broken or it cannot accurately mimic the target platform(s).
I appreciate all your efforts in answering, I simply don’t buy that I’m specifically doing something wrong in the C++ code.
I’m happy to enable the debug feature so you can troubleshoot your issue further. Just let me know.
Thank you, BanzaiMan, I would appreciate that.