Hey,All: I tried to update software from source by ports, then find that kdepim-addons, kitinerary and libphonenumber can not build correctly. After read the Makefile inside their ports tree, I realized that kdepim-adeons depend on kitineray which depend on libphonenumber. When upgrade the libphonenumber, the first ERROR message is "fatal error: 'google/protobuf/inlined_string_field.h' file not found" So I check the devel/protobuf plist file, and find that their is no such header file would install to the system. I also tried to find / -name 'inlined_string_field.h' in my whole computer, and nothing found. Now the devel/protobuf version is 3.14.0, which can not support to build /devel/libphonenumber. Please fixed that problem. Thanks.
Hey Guys, Since there is no one response, I tried to fix it by my self, and finally done. It seems the older version of libphonenumber header files in /usr/local/include/phonenumber would need this 'google/protobuf/inlined_string_field.h'. When compiler it, the 'make' process automatically find the system include path instead of ports path of include file. So I delete the older version by 'make deinstall' to delete all /usr/local/include/phonenumber directory. Then re-make it. Now everything is fine! So, this bug is due to API change and the stupid c 'include <somepath/somefile.h>' mechanism. One should change the CMakeList.txt file to blacklist the /usr/local/include path. otherwise, this kind of ERROR would happen again and again!
Fix summary and assign it to the maintainer.
(In reply to marshall from comment #1) Moin moin It is advisable to build ports in poudriere or an other clean-room builder, so that exactly this issue won't happen. Unfortunately it is generally not easy to make ports not pick up their own headers of the old version. mfg Tobias
To add to what Tobias said: on Linux "everything" lives in `/usr/include`, which isn't explicitly added as an include path. It's implicitly a system-include path, just like on FreeBSD. But because we install all the non-system headers in `/usr/local/include`, that path needs to be added to the header search-path. That can be done with `-I` or `-isystem`, and as soon as that happens, it is both explicit, and somewhere specific in the search-order. So any package on FreeBSD that installs headers to `/usr/local/include` *and also* has any dependency with headers in `/usr/local/include` has a problem: the `-I` for `/usr/local/include` must come **after** any `-I` for the package's internal headers. Setting that up is something that very few package-build-system do (e.g. you need to be very very careful in handling include paths, whether you use autoconf, cmake or something else). Each individual package needs patching / massaging to get that right. And that's why "build in a clean environment" is the recommended and inexpensive workaround, and why patches for specific ports are welcome. libphonenumber is special, the build is also full of race-conditions, but that's because Google is awful.