-
Notifications
You must be signed in to change notification settings - Fork 72
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
Compilation warnings on ArchLinux #176
Comments
Also, if bin folder is not existing and make is run with several threads (
This is a problem because when building the AUR package it is triggered (as it starts with a clean plate and no bin folder) |
Thanks! I'll try to get to these, but probably not today. |
Regarding #176 (comment), it appears it’s easy to fix by adding the same |
Committed 0f10a5a |
Comitted 9f3b63d which should fix the issue that "make -j5" with ./bin failing to exist and crapping out at that particular point. However, if I do:
I still (sometimes, not always) see things like:
which I don't yet understand. |
Nice fix for bin folder, I guess all the other mkdir bin should be removed then. |
Good idea. Done. 902adfb
It was due to concurrent execution of multiple instances of (cd ssgl; make). Fixed by 1a3b0bd Edit: I should add, I think it's fixed. Previously it didn't fail every time, but every other time or so. I ran "make mostly-clean; rmdir bin; make -j8" about 10 times in a row without a failure though. |
@smcameron, I am using gcc 8.3.1 and make 4.2.1 on Fedora 29. I have no apparent problems with dependencies, but I get a lot of the same compilation warnings like those in the OP. I also noticed the following: in files that get the warnings, I also see snis_client.c: At top level: This appears in a number of files. However, the first problem I encountered when doing a make all is that I get make: *** No rule to make target 'bin', needed by 'all'. Stop. So, I go and delete the 'bin' target after 'all:' and the project compiles! There must be some default dependency for bin that is absent in my environment, that is all I can figure, because how does it compile for you if the target definition is missing? Odd. But, you are more familiar with your code, so I wanted to check with you to see if it is OK to remove the 'bin' reference. |
@bmdrake919 Thanks, for pointing that out. I think I happen to have bin/ lying around. If I "rm -fr bin", I can duplicate your problem. I'll try to solve it. |
@bmdrake919 Ok, I think 24a0b37 should fix it. Let me know if it doesn't, or if you bump into anything else. |
I tried to look into the «directive output may be truncated» and «'strncpy' output may be truncated copying…» warnings and from what I understand these are shown because in case strncpy truncates, it does not add the NULL terminating characters (and for snprintf it seems to depend on implementations). That said, fixing those is a bit hard as it means you always need to have a big enough destination to contain all the input. The best way may be writing a new function that does truncate if needed but adds the \0 terminating char in all cases (and maybe even \n if wanted). Note that from What I understood gcc will not complain if you are testing the result of snprintf, because it then considers that you handle the case where truncation happens (as the result is >0 in this case). Not sure if this is worth the hassle. |
I changed a bunch of sprintf to snprintf with:
But there are still some left:
|
On linux, it seems to truncate with a '\0' inserted early if need be.
|
Hello,
As explained in #25 earlier, I get a lot of warnings when building with gcc 8.2.1.
Here is stderr:
The text was updated successfully, but these errors were encountered: