Bug #2409: Headers check fails on FreeBSD - ndn-cxx - NDN project issue tracking system

Actions

Copy link

Bug #2409

open

Headers check fails on FreeBSD

Added by Junxiao Shi about 9 years ago. Updated 6 months ago.

Status:

New

Priority:

Low

Assignee:

Category:

Build

Target version:

Start date:

Due date:

% Done:

Estimated time:

3.00 h

Tags:

FreeBSD

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)

Actions

Copy link

Updated by Junxiao Shi about 9 years ago

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.

Actions

Copy link

Updated by Junxiao Shi about 9 years ago

Project changed from NFD to ndn-cxx
Category changed from Build to Build
Target version changed from v0.3 to v0.3

Actions

Copy link

Updated by Alex Afanasyev about 9 years ago

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?

Actions

Copy link

Updated by Junxiao Shi about 9 years ago

Question: how was this script working without PKG_CONFIG_PATH on OSX?

Actions

Copy link

Updated by Alex Afanasyev about 9 years ago

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.

Actions

Copy link

Updated by Junxiao Shi about 9 years ago

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.

Actions

Copy link

Updated by Junxiao Shi almost 9 years ago

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.

Actions

Copy link

Updated by Junxiao Shi almost 9 years ago

Status changed from New to In Progress
Target version changed from v0.3 to v0.4

Actions

Copy link

Updated by Junxiao Shi almost 9 years ago

% 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?

Actions

Copy link

#10

Updated by Junxiao Shi almost 9 years ago

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.

Actions

Copy link

#11

Updated by Davide Pesavento about 4 years ago

Subject changed from standalone-header-compilation.sh is failing on FreeBSD to Headers check fails on FreeBSD
Start date deleted (~~01/24/2015~~)

Actions

Copy link

#12