Bug #2409
open
Headers check fails on FreeBSD
Added by Junxiao Shi over 9 years ago.
Updated 6 months ago.
Description
http://jenkins.named-data.net/job/ndn-cxx/1914/OS=FreeBSD10/console
Run: /usr/home/jenkins/workspace/ndn-cxx/OS/FreeBSD10/.jenkins.d/40-standalone-header-compilation.sh
Compiler flags: g++
Verifying standalone header compilation for common-pch.hpp
Package libndn-cxx was not found in the pkg-config search path.
Perhaps you should add the directory containing `libndn-cxx.pc'
to the PKG_CONFIG_PATH environment variable
Package 'libndn-cxx', required by 'world', not found
/usr/home/jenkins/workspace/ndn-cxx/OS/FreeBSD10/.jenkins.d/40-standalone-header-compilation.sh: line 29: g++: command not found
Verifying standalone header compilation for common.hpp
Package libndn-cxx was not found in the pkg-config search path.
Perhaps you should add the directory containing `libndn-cxx.pc'
to the PKG_CONFIG_PATH environment variable
Package 'libndn-cxx', required by 'world', not found
/usr/home/jenkins/workspace/ndn-cxx/OS/FreeBSD10/.jenkins.d/40-standalone-header-compilation.sh: line 29: g++: command not found
Related issues
1 (1 open — 0 closed)
I prefer not to take this issue. I don't have time to deploy a FreeBSD box until Jan 26 or later. Someone who has FreeBSD should work on this.
- Project changed from NFD to ndn-cxx
- Category changed from Build to Build
- Target version changed from v0.3 to v0.3
There are two problems because of the script assumptions. One way to solve them is to set PKG_CONFIG_PATH and CXX variables for the slave. Another way add more logic to the script (replicate dome logic in waf).
The first way simple and requires no extra code, but it is making CI environment on the slave "not clean".
Which way you want to solve the problem?
Question: how was this script working without PKG_CONFIG_PATH on OSX?
On OSX, the default paths that pkg-config is looking are /usr/lib/pkgconfig and /usr/local/lib/pkgconfig, so there is not special handling is necessary. The similar default exists in Ubuntu platform. I know for sure that on Fedora (and I think CentOS, but not sure) the only default is /usr/lib/pkgconfig.
I looked a little deeper on FreeBSD and discovered that it uses different paths for pkgconfig files: /usr/libdata/pkgconfig/ /usr/local/libdata/pkgconfig/. Unless there are extra flags in the environment (I can set the for the slave), pkg-config will not be able to discover things.
In any case. For immediate solution, I'll add flags. We can think how to handle it better later.
- Priority changed from Immediate to Normal
One possibility is converting this script into a waf build target.
This has been proposed before but wasn't necessary at that time.
If this approach is chosen, estimated time would be 3 hours.
- Assignee set to Junxiao Shi
- Estimated time changed from 1.00 h to 3.00 h
We have Vagrant now so I'll give this a shot using the approach outlined in note-6.
- Status changed from New to In Progress
- Target version changed from v0.3 to v0.4
- % Done changed from 0 to 10
I spent a lot of time trying to deploy the FreeBSD box.
First I made the mistake of choosing FreeBSD 11, only to find that its pkg command has a bug.
And then I realize that FreeBSD 11 is not released yet.
Then I tried FreeBSD 10.1.
The steps differ from Compiling on FreeBSD 100 as follows:
- dependency packages:
devel/boost-all security/cryptopp databases/sqlite3 net/libpcap devel/git lang/python devel/pkgconf
./waf configure --debug works by itself, no CXXFLAGS is necessary
I'm able to reproduce this Bug, but the error message is different:
[vagrant@vagrant-freebsd-101-amd64 ~/ndn-cxx]$ .jenkins.d/40-standalone-header-compilation.sh
Compiler flags: g++
.jenkins.d/40-standalone-header-compilation.sh: line 32: /dev/fd/62: No such file or directory
No header found. Is ndn-cxx installed?
- Status changed from In Progress to New
- Assignee deleted (
Junxiao Shi)
- Target version changed from v0.4 to Unsupported
- % Done changed from 10 to 0
I had no progress on this issue after being able to reproduce it, because I don't have enough experience on waf.
I identify the following questions in making standalone-header-compilation a build target:
- How to traverse the dependency tree when
./waf standalone-header-compilation (or a similar command line) is invoked?
- How to determine whether a header is installed or not?
Some headers, such as
**/detail/*.hpp, are not installed, and are not required to be standalone-compilable.
- How to avoid the effect of current path?
Suppose
security/identity-certificate.hpp contains #include "data.hpp", it would compile within ndn-cxx repository, but would fail when installed because it's not a relative path.
I won't work on this anymore. Target version is changed to Unsupported because FreeBSD has never been a supported platform.
- Subject changed from standalone-header-compilation.sh is failing on FreeBSD to Headers check fails on FreeBSD
- Start date deleted (
01/24/2015)
- Target version deleted (
Unsupported)
- Tags set to FreeBSD
- Priority changed from Normal to Low
- Related to Bug #4859: libndn-cxx.pc installed in wrong location on FreeBSD added
Also available in: Atom
PDF
Updated by 
Updated by 
Updated by