On 04.08.2011 23:54, Ulrich Prinz wrote: > Hi Oliver, > > On 04.08.2011 19:35, Oliver Hartkopp wrote: >>> That should be easy too, I thought... >>> I have those can-utils in my target code so I just copied cangw.c there and >>> added it to the Makefile.... >>> Then I rewrote the Makefile to be less talking and more informative... >>> Then I hardened the compiler flags and then I was busy to remove all those >>> double- and shadow-declarations from all of the tools, including cangw.c... >> >> ??? - what do you mean in detail? Something to improve? >> > I don't remember all now, but will make a diff against your release. > Somewhere between kernel 2.6.34 and 2.6.39 the can.h has moved from > socetcan/can.h to include/linux/can.h.
Not really! Not to mix the includes from mainline and SocketCAN SVN we placed the SVN includes in include/socketcan/can... I forgot to mention the tool trunk/strip-src that generates a source code for a specific kernel version and also replaces the SVN includes with real mainline includes, e.g. try: ~/socketcan/trunk$ ./strip-src -v 2.6.39 -i -m kernel/2.6/net/can/gw.c | less It creates a clean source for the 2.6.39 you can copy to linux/net/can/gw.c Same with: ./strip-src -v 2.6.39 -i -m kernel/2.6/include/socketcan/can/gw.h > gw.h I assume this makes it much easier for you :-) > > Then I compile projects with -wshadow and other warnings enabled. > So I came accross that you extern declarate variables of the command > line parsing library. That leads to warnings. In other places functions > have variables declared that shadow global variables. > From past projects I learned how painful that could be. So I let no code > pass to a project that gives these warnings. Good point. I'll take a look at that. > Normally I accept no warnings, but even kernel 2.6.39 gives some that I > had no time to dig down. > > Could be that the command line library moved in the header files to a > position where it is no found by the code. I think it is in <unistd.h>. You talk about getopt() and friends? Yes that is in unistd.h > And the Makfile I used was the one provided by the can-utils, not the > one you provided. It was full of long lists of files and didn't really > fit in our build system. So I felt it was better to rewrite it for ease > of use and understanding. > Not all of us could read and write Makefiles... (If I catch the guy who > invented this syntax...) /me too :-)) Regards, Oliver _______________________________________________ Socketcan-users mailing list [email protected] https://lists.berlios.de/mailman/listinfo/socketcan-users
