cmake-native trouble making

cmake-native trouble making

[Jaap de Jong]

During a clean build (tmp removed) I get this error

$ bitbake cmake-native
////
| [ 87%] Building CXX object 
Source/CMakeFiles/CPackLib.dir/CPack/cmCPackNSISGenerator.o
| /usr/bin/ld: cannot find -ltinfo
| collect2: ld returned 1 exit status
| make[2]: *** [bin/ccmake] Error 1
| make[1]: *** [Source/CMakeFiles/ccmake.dir/all] Error 2
| make[1]: *** Waiting for unfinished jobs....
////

Is cmake-native_2.8.2.bb missing this line:

     RDEPENDS = "ncurses-terminfo"

Re: cmake-native trouble making

[Enrico Scholz]

Jaap de Jong <jaap.dejong@nedap.com> writes:

> $ bitbake cmake-native
> ////
> | [ 87%] Building CXX object
> Source/CMakeFiles/CPackLib.dir/CPack/cmCPackNSISGenerator.o
> | /usr/bin/ld: cannot find -ltinfo
> | collect2: ld returned 1 exit status
> | make[2]: *** [bin/ccmake] Error 1
> | make[1]: *** [Source/CMakeFiles/ccmake.dir/all] Error 2
> | make[1]: *** Waiting for unfinished jobs....
> ////
>
> Is cmake-native_2.8.2.bb missing this line:
>
>     RDEPENDS = "ncurses-terminfo"

no, 'DEPENDS = "ncurses-native"'; BUT:

* it will cause problems on (host)distributions which do not have libtinfo
  (e.g. RHEL5) and have ncurses-native in their ASSUME_PROVIDED

* some hours ago I added a libtermcap.so compatibility symlink to
  ncurses(-native) so that 5ea3047995421d99f7f3537cb8f9ae23f3185a9f
  might not be needed anymore

* build of the curses frontend should be disabled for cmake-native because
  we do automated builds only; I do not know atm how to configure cmake
  for this...


Enrico

Re: cmake-native trouble making

[Tom Rini]

Enrico Scholz wrote:
> Jaap de Jong <jaap.dejong@nedap.com> writes:
> 
>> $ bitbake cmake-native
>> ////
>> | [ 87%] Building CXX object
>> Source/CMakeFiles/CPackLib.dir/CPack/cmCPackNSISGenerator.o
>> | /usr/bin/ld: cannot find -ltinfo
>> | collect2: ld returned 1 exit status
>> | make[2]: *** [bin/ccmake] Error 1
>> | make[1]: *** [Source/CMakeFiles/ccmake.dir/all] Error 2
>> | make[1]: *** Waiting for unfinished jobs....
>> ////
>>
>> Is cmake-native_2.8.2.bb missing this line:
>>
>>     RDEPENDS = "ncurses-terminfo"
> 
> no, 'DEPENDS = "ncurses-native"'; BUT:
> 
> * it will cause problems on (host)distributions which do not have libtinfo
>   (e.g. RHEL5) and have ncurses-native in their ASSUME_PROVIDED

Isn't the whole point of ASSUME_PROVIDED that user be aware?

> 
> * some hours ago I added a libtermcap.so compatibility symlink to
>   ncurses(-native) so that 5ea3047995421d99f7f3537cb8f9ae23f3185a9f
>   might not be needed anymore

Um, is there a reason this wasn't just done as a ln within the recipe?

-- 
Tom Rini
Mentor Graphics Corporation

Re: cmake-native trouble making

[Enrico Scholz]

Tom Rini <tom_rini@mentor.com> writes:

>>> | /usr/bin/ld: cannot find -ltinfo
>>
>> no, 'DEPENDS = "ncurses-native"'; BUT:
>>
>> * it will cause problems on (host)distributions which do not have libtinfo
>>   (e.g. RHEL5) and have ncurses-native in their ASSUME_PROVIDED
>
> Isn't the whole point of ASSUME_PROVIDED that user be aware?

Would be too arbitrary in this case because it forces people to check by
trial & error whether ASSUME_PROVIDED are working.  A raw guideline for
adding an entry to ASSUME_PROVIDED should be, whether a corresponding,
recent -devel package has been installed on the host.

imo, packages should not have so strict requirements on the actual
provider but check in their configure task what to use (this includes
autodetection of libtinfo vs. libtermcap vs. libncurses).


For cmake, problem above can by solved by an initial configuration
script having

| SET (BUILD_CursesDialog OFF CACHE BOOL "" FORCE)


>> * some hours ago I added a libtermcap.so compatibility symlink to
>>   ncurses(-native) so that 5ea3047995421d99f7f3537cb8f9ae23f3185a9f
>>   might not be needed anymore
>
> Um, is there a reason this wasn't just done as a ln within the recipe?

It's a mix of personal preference, following Fedora's packaging of this
file and the hope to use some more of the power of linker scripts (giving
out a deprecated warning, add AS_NEEDED, linking against multiple files).
There was no opposition when I wrote about linker scripts neither.

Perhaps I should have made it inline by 'echo INPUT(-ltinfo) > ...' but
I did not saw this when I committed the patch.



Enrico

Re: cmake-native trouble making

[Tom Rini]

Enrico Scholz wrote:
> Tom Rini <tom_rini@mentor.com> writes:
> 
>>>> | /usr/bin/ld: cannot find -ltinfo
>>> no, 'DEPENDS = "ncurses-native"'; BUT:
>>>
>>> * it will cause problems on (host)distributions which do not have libtinfo
>>>   (e.g. RHEL5) and have ncurses-native in their ASSUME_PROVIDED
>> Isn't the whole point of ASSUME_PROVIDED that user be aware?
> 
> Would be too arbitrary in this case because it forces people to check by
> trial & error whether ASSUME_PROVIDED are working.  A raw guideline for
> adding an entry to ASSUME_PROVIDED should be, whether a corresponding,
> recent -devel package has been installed on the host.

That seems totally backwards.  The guideline for adding an entry to 
ASSUME_PROVIDED is that you know better than the build system.  No one 
doing commits for native packages should have anything set, or at least 
confirming that having an empty set (aside from bitbake.conf anyhow...) 
works fine too as that's the common case.

> imo, packages should not have so strict requirements on the actual
> provider but check in their configure task what to use (this includes
> autodetection of libtinfo vs. libtermcap vs. libncurses).

Yes, and we're grappling with the fallout of a big switch, which 
includes fixing up (or upgrading) other packages to be happy with a 
given version.

> For cmake, problem above can by solved by an initial configuration
> script having
> 
> | SET (BUILD_CursesDialog OFF CACHE BOOL "" FORCE)
>

Great, lets do that.

> 
>>> * some hours ago I added a libtermcap.so compatibility symlink to
>>>   ncurses(-native) so that 5ea3047995421d99f7f3537cb8f9ae23f3185a9f
>>>   might not be needed anymore
>> Um, is there a reason this wasn't just done as a ln within the recipe?
> 
> It's a mix of personal preference, following Fedora's packaging of this
> file and the hope to use some more of the power of linker scripts (giving
> out a deprecated warning, add AS_NEEDED, linking against multiple files).
> There was no opposition when I wrote about linker scripts neither.
> 
> Perhaps I should have made it inline by 'echo INPUT(-ltinfo) > ...' but
> I did not saw this when I committed the patch.

Well, it wasn't at all clear from the commit message why anything more 
than a symlink was done.  So can you please add a comment and a commit 
message explaining what's going on here?  Thanks!

-- 
Tom Rini
Mentor Graphics Corporation