fix compile error on mac high sierra for uint type

[tgruben]

when executing go build the following error was produced
./ncs.h:11:3: error: unknown type name 'uint'; did you mean 'int'?

[deadprogram]

Hello @tgruben thanks for the PR. Just wondering however, under what circumstances you receive this error. Several of us have high sierra installed, but do not receive that compile error. Can you please provide a little more info? Thank you.

[deadprogram]

My man @milosgajdos83 asks what gcc version you have installed? Might be https://stackoverflow.com/questions/43892984/gcc-5-6-and-7-on-osx-do-not-support-uint

[tgruben]

Certainly,

• Followed the macos install statements exactly in $HOME/3rd/.
• Added a new directory into my $GOPATH
• created the most basic dump the device info code in main.go
• Ran dep init

$ go build

ncs/stepn/vendor/github.com/hybridgroup/go-ncs

In file included from vendor/github.com/hybridgroup/go-ncs/ncs.go:5:
./ncs.h:11:3: error: unknown type name 'uint'; did you mean 'int'?
uint length;
^~~~
int
1 error generated.

$ gcc --version Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr --with-gxx-include-dir=/usr/include/c++/4.2.1 Apple LLVM version 9.1.0 (clang-902.0.39.2) Target: x86_64-apple-darwin17.7.0 Thread model: posix InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin 08

[milosgajdos]

This is super strange @tgruben . The following code in ncs.h should avoid the issues you're seeing.

#ifdef __APPLE__
#include <sys/types.h>
#endif // __APPLE__

In my case the headers are in the following directory as the ifdef directive specifies

/usr/include/sys

And the unsigned int typdef is there:

$ pwd
/usr/include/sys
$ grep "unsigned int" types.h
typedef	unsigned int		uint;		/* Sys V compatibility */

My wild guess is the header files in your case are being read from some "non-standard" location
Can you please send in the output of cpp -v as I think this might be related to where gcc look for the header files in the order of appearance.

Another thing I'm wondering is whether #ifdef __APPLE__ clause for some reason is not expanded by the preprocessor for some reason, alas like I said the include directory order might be different.

Maybe running cpp -v might give you some hints?

[milosgajdos]

I've also seen some people suggesting xcode-select --install to reinstall Xcode stuff which then places all the header files in the right directories. But I'd start looking into the include paths and into the presence of the right header files - in this case sys/types.h

Given that #ifdef __APPLE__ clause does work properly with your version of gcc of course. But like I said sometime C and C++ header and include paths get messed up.

[tgruben]

i'll give the reinstall a try, below is the output of my current cpp -v for reference
$ cpp -v Apple LLVM version 9.1.0 (clang-902.0.39.2) Target: x86_64-apple-darwin17.7.0 Thread model: posix InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin "/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang" -cc1 -triple x86_64-apple-macosx10.13.0 -Wdeprecated-objc-isa-usage -Werror=deprecated-objc-isa-usage -E -disable-free -disable-llvm-verifier -discard-value-names -main-file-name - -mrelocation-model pic -pic-level 2 -mthread-model posix -mdisable-fp-elim -fno-strict-return -masm-verbose -munwind-tables -target-cpu penryn -target-linker-version 351.8 -v -dwarf-column-info -debugger-tuning=lldb -resource-dir /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/clang/9.1.0 -I /usr/include -fdebug-compilation-dir /Users/toddgruben -ferror-limit 19 -fmessage-length 80 -stack-protector 1 -fblocks -fobjc-runtime=macosx-10.13.0 -fencode-extended-block-signature -fmax-type-align=16 -fdiagnostics-show-option -fcolor-diagnostics -traditional-cpp -o - -x c - clang -cc1 version 9.1.0 (clang-902.0.39.2) default target x86_64-apple-darwin17.7.0 ignoring duplicate directory "/usr/include" as it is a non-system directory that duplicates a system directory #include "..." search starts here: #include <...> search starts here: /usr/local/include /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/clang/9.1.0/include /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include /usr/include /System/Library/Frameworks (framework directory) /Library/Frameworks (framework directory) End of search list.

[milosgajdos]

The only thing I can see in there is the lower version of clang than the one on my machine but that should not matter as long as the sys/types.h includes kicks in.

Do you see sys/types.h file in /usr/include/ directory?

If the header file does exist, can you check if typedef unsigned int uint exists in it?

[tgruben]

yep, lovely line 92 ` 92 typedef unsigned int uint; /* Sys V compatibility */ ` so odd

…

On Sun, Sep 16, 2018 at 3:37 PM Milos Gajdos ***@***.***> wrote: The only thing I can see in there is the lower version of clang than the one on my machine but that should not matter as long as the sys/types.h includes kicks in. Do you see sys/types.h file in /usr/include/ directory? If the header file does exist, can you check if typedef unsigned int uint exists in it? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#4 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AA2Q48__joebPBDrQLBe9Msh39mb4kBMks5ubraRgaJpZM4WUAbe> .