build failure on OSX

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

build failure on OSX

Carlo de Falco-2
Hi,

I just pulled from the repo default branch and tried to build revision 90689bdbe048.
The buold fails wit the error :

../octave/libinterp/version.cc:92:20: error: no member named 'config' in namespace 'octave'
         + octave::config::canonical_host_type ()
           ~~~~~~~~^

It seems this is due to the fact that libinterp/version.cc has

  #include "defaults.h"

but defaults.h is in the subdirectory libinterp/corefcn, using

 #include "corefcn/defaults.h"

fixes this problem for me, but then I get similar issues in other files, for example:

../octave/libinterp/octave-value/ov-dld-fcn.cc:51:38: error: no member named 'config' in namespace 'octave'
  std::string oct_file_dir = octave::config::oct_file_dir ();

was defaults.h recently moved? what is a clean way to deal with this? Is anyone else seing the same problem? should I file a bug?

thanks,
c.




Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: build failure on OSX

Daniel Sebald
On 07/28/2017 03:06 PM, Carlo De Falco wrote:

> Hi,
>
> I just pulled from the repo default branch and tried to build revision 90689bdbe048.
> The buold fails wit the error :
>
> ../octave/libinterp/version.cc:92:20: error: no member named 'config' in namespace 'octave'
>          + octave::config::canonical_host_type ()
>            ~~~~~~~~^
>
> It seems this is due to the fact that libinterp/version.cc has
>
>   #include "defaults.h"
>
> but defaults.h is in the subdirectory libinterp/corefcn, using
>
>  #include "corefcn/defaults.h"
>
> fixes this problem for me, but then I get similar issues in other files, for example:
>
> ../octave/libinterp/octave-value/ov-dld-fcn.cc:51:38: error: no member named 'config' in namespace 'octave'
>   std::string oct_file_dir = octave::config::oct_file_dir ();
>
> was defaults.h recently moved? what is a clean way to deal with this? Is anyone else seing the same problem? should I file a bug?

Perhaps try a fresh clone of the repository from scratch first.  If
there is a change in header location, sometime lingering older versions
in a build tree might get found ahead of the newer one.  Or something
like that...

Dan

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: build failure on OSX

bpabbott
Administrator
> On Jul 28, 2017, at 16:27, Daniel J Sebald <[hidden email]> wrote:
>
>> On 07/28/2017 03:06 PM, Carlo De Falco wrote:
>> Hi,
>>
>> I just pulled from the repo default branch and tried to build revision 90689bdbe048.
>> The buold fails wit the error :
>>
>> ../octave/libinterp/version.cc:92:20: error: no member named 'config' in namespace 'octave'
>>         + octave::config::canonical_host_type ()
>>           ~~~~~~~~^
>>
>> It seems this is due to the fact that libinterp/version.cc has
>>
>>  #include "defaults.h"
>>
>> but defaults.h is in the subdirectory libinterp/corefcn, using
>>
>> #include "corefcn/defaults.h"
>>
>> fixes this problem for me, but then I get similar issues in other files, for example:
>>
>> ../octave/libinterp/octave-value/ov-dld-fcn.cc:51:38: error: no member named 'config' in namespace 'octave'
>>  std::string oct_file_dir = octave::config::oct_file_dir ();
>>
>> was defaults.h recently moved? what is a clean way to deal with this? Is anyone else seing the same problem? should I file a bug?
>
> Perhaps try a fresh clone of the repository from scratch first.  If there is a change in header location, sometime lingering older versions in a build tree might get found ahead of the newer one.  Or something like that...
>
> Dan

Or just "hg purge" and then try a build?

Ben
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: build failure on OSX

Carlo de Falco-2


Il 28 lug 2017 10:37 PM, "Ben Abbott" <[hidden email]> ha scritto:
> On Jul 28, 2017, at 16:27, Daniel J Sebald <[hidden email]> wrote:

> Perhaps try a fresh clone of the repository from scratch first.  If there is a change in header location, sometime lingering older versions in a build tree might get found ahead of the newer one.  Or something like that...
>
> Dan

Or just "hg purge" and then try a build?

Ben

Hi,

Indeed I have a file named defaults.h in the build directory that is completely different from that in the source directory. 

Deleting that file fixed the build.

Thanks,
c.
Loading...