Cmake broken on freemantle
Cmake broken on freemantle
Re: Cmake broken on freemantle
2009-08-26 11:00 UTC
[CC'ing the last uploader for the package, according to the debian/changelog]
On Wed, Aug 26, 2009 at 5:12 AM, Graham Cobb<g+770@cobb.uk.net> wrote:
> Cmake is required to build opensync. It works fine on Diablo. However, in
> the Fremantle SDK it is broken (segfault during "Check for working C
> compiler:" step).
>
> Cmake is not part of the SDK (it should be, but that is another matter). It
> is in extras-devel.
>
> Does anyone know who packaged cmake? The maintainer field is still set to
> upstream but it has a "maemo" version number. Any volunteers to work out why
> cmake is not working and/or to try repackaging it?
Well, we had the same problem so we produced a modified version that
is built using sbox's host-g++/host-gcc. This allows to use the same
binary both in x86 and ARMEL targets, and is a lot faster on ARMEL
(and does not segfault).
The "catch" is that, given that the binary is actually compiled for
x86, it will not run if installed on the device. It will only work on
Scratchbox.
So I ask other developers using cmake (I suppose there are not that
many, otherwise the problem would be reported sooner, given that cmake
+ fremantle + ARMEL always segfaults): is it acceptable for you?
Note that this is in fact a qemu bug, but doing the compilation with
host-gcc/host-g++ did the trick and is easier than debugging qemu.
If others agree, I can produce a patch against the latest version in
fremantle-extras devel and upload a new version for cmake.
Regards,
--
Anderson Lizardo
OpenBossa Labs - INdT
Manaus - Brazil
On Wed, Aug 26, 2009 at 5:12 AM, Graham Cobb<g+770@cobb.uk.net> wrote:
> Cmake is required to build opensync. It works fine on Diablo. However, in
> the Fremantle SDK it is broken (segfault during "Check for working C
> compiler:" step).
>
> Cmake is not part of the SDK (it should be, but that is another matter). It
> is in extras-devel.
>
> Does anyone know who packaged cmake? The maintainer field is still set to
> upstream but it has a "maemo" version number. Any volunteers to work out why
> cmake is not working and/or to try repackaging it?
Well, we had the same problem so we produced a modified version that
is built using sbox's host-g++/host-gcc. This allows to use the same
binary both in x86 and ARMEL targets, and is a lot faster on ARMEL
(and does not segfault).
The "catch" is that, given that the binary is actually compiled for
x86, it will not run if installed on the device. It will only work on
Scratchbox.
So I ask other developers using cmake (I suppose there are not that
many, otherwise the problem would be reported sooner, given that cmake
+ fremantle + ARMEL always segfaults): is it acceptable for you?
Note that this is in fact a qemu bug, but doing the compilation with
host-gcc/host-g++ did the trick and is easier than debugging qemu.
If others agree, I can produce a patch against the latest version in
fremantle-extras devel and upload a new version for cmake.
Regards,
--
Anderson Lizardo
OpenBossa Labs - INdT
Manaus - Brazil
Re: Cmake broken on freemantle
2009-08-26 12:42 UTC
On Wednesday 26 August 2009 12:00:50 Anderson Lizardo wrote:
> Well, we had the same problem so we produced a modified version that
> is built using sbox's host-g++/host-gcc. This allows to use the same
> binary both in x86 and ARMEL targets, and is a lot faster on ARMEL
> (and does not segfault).
The problem with that seems to be that you can't predict what the host is.
For example, I use both 32-bit and 64-bit hosts. And there have, in the
past, been libc version problems between different linux distributions.
> The "catch" is that, given that the binary is actually compiled for
> x86, it will not run if installed on the device. It will only work on
> Scratchbox.
I'm not keen on having a host binary in a package in extras-devel. If we have
to go down this route I think we need to find a different repository for this
hacked cmake to live in.
> So I ask other developers using cmake (I suppose there are not that
> many, otherwise the problem would be reported sooner, given that cmake
> + fremantle + ARMEL always segfaults): is it acceptable for you?
I don't think there are many packages using cmake, but I think there are a
few.
There are two big problems I see:
1) There is not one host to build this for but several. And it has to be kept
up to date or else we suddenly can't build some packages.
2) We also have to make it work in the autobuilder (how do you deal with that
problem today?).
> Note that this is in fact a qemu bug, but doing the compilation with
> host-gcc/host-g++ did the trick and is easier than debugging qemu.
Thanks for finding out the problem is in qemu.
> If others agree, I can produce a patch against the latest version in
> fremantle-extras devel and upload a new version for cmake.
Could there be some way to use the actual host cmake instead of a special
package? That would get round the problem of having to have different
packages for different hosts. If so, maybe the package could set up the
magic needed to invoke the host's cmake.
Alternatively, any chance we could persuade the scratchbox developers to build
scratchbox cmake packages along with the rest of scratchbox? They could then
be provided along with the scratchbox packages for each different
disrtibution.
Graham
> Well, we had the same problem so we produced a modified version that
> is built using sbox's host-g++/host-gcc. This allows to use the same
> binary both in x86 and ARMEL targets, and is a lot faster on ARMEL
> (and does not segfault).
The problem with that seems to be that you can't predict what the host is.
For example, I use both 32-bit and 64-bit hosts. And there have, in the
past, been libc version problems between different linux distributions.
> The "catch" is that, given that the binary is actually compiled for
> x86, it will not run if installed on the device. It will only work on
> Scratchbox.
I'm not keen on having a host binary in a package in extras-devel. If we have
to go down this route I think we need to find a different repository for this
hacked cmake to live in.
> So I ask other developers using cmake (I suppose there are not that
> many, otherwise the problem would be reported sooner, given that cmake
> + fremantle + ARMEL always segfaults): is it acceptable for you?
I don't think there are many packages using cmake, but I think there are a
few.
There are two big problems I see:
1) There is not one host to build this for but several. And it has to be kept
up to date or else we suddenly can't build some packages.
2) We also have to make it work in the autobuilder (how do you deal with that
problem today?).
> Note that this is in fact a qemu bug, but doing the compilation with
> host-gcc/host-g++ did the trick and is easier than debugging qemu.
Thanks for finding out the problem is in qemu.
> If others agree, I can produce a patch against the latest version in
> fremantle-extras devel and upload a new version for cmake.
Could there be some way to use the actual host cmake instead of a special
package? That would get round the problem of having to have different
packages for different hosts. If so, maybe the package could set up the
magic needed to invoke the host's cmake.
Alternatively, any chance we could persuade the scratchbox developers to build
scratchbox cmake packages along with the rest of scratchbox? They could then
be provided along with the scratchbox packages for each different
disrtibution.
Graham
Re: Cmake broken on freemantle
2009-08-26 13:50 UTC
On Wed, Aug 26, 2009 at 8:42 AM, Graham Cobb<g+770@cobb.uk.net> wrote:
> On Wednesday 26 August 2009 12:00:50 Anderson Lizardo wrote:
>> Well, we had the same problem so we produced a modified version that
>> is built using sbox's host-g++/host-gcc. This allows to use the same
>> binary both in x86 and ARMEL targets, and is a lot faster on ARMEL
>> (and does not segfault).
>
> The problem with that seems to be that you can't predict what the host is.
> For example, I use both 32-bit and 64-bit hosts. And there have, in the
> past, been libc version problems between different linux distributions.
I think you got it wrong... It will build with host-g++/host-gcc, so
it will be built with the same compiler (and linked to the same
libraries) as other internal sbox tools were compiled. Therefore, if
scratchbox works in your host, cmake compiled with host-g++ will work
too. It will not link to any host libraries, only to internal
scratchbox ones.
Unless you did not use the official sbox binaries (e.g. compiled from
sources) it should work.
If you don't know, "host-g++" is a internal scratchbox compiler used
to compile all "native" tools provided by scratchbox, that work on
both targets.
>> The "catch" is that, given that the binary is actually compiled for
>> x86, it will not run if installed on the device. It will only work on
>> Scratchbox.
>
> I'm not keen on having a host binary in a package in extras-devel. If we have
> to go down this route I think we need to find a different repository for this
> hacked cmake to live in.
That's the main reason I've been keeping it private so far. :/
>> So I ask other developers using cmake (I suppose there are not that
>> many, otherwise the problem would be reported sooner, given that cmake
>> + fremantle + ARMEL always segfaults): is it acceptable for you?
>
> I don't think there are many packages using cmake, but I think there are a
> few.
...That for some reason do not trigger the segfault on ARMEL :/
> There are two big problems I see:
>
> 1) There is not one host to build this for but several. And it has to be kept
> up to date or else we suddenly can't build some packages.
See my first comment above.
> 2) We also have to make it work in the autobuilder (how do you deal with that
> problem today?).
it will just work, because cmake compiled with host-g++ will work like
any other scratchbox internal tool.
> Alternatively, any chance we could persuade the scratchbox developers to build
> scratchbox cmake packages along with the rest of scratchbox? They could then
> be provided along with the scratchbox packages for each different
> disrtibution.
Again the approach I mentioned above is basically the same the sbox
developers use to building their "devkit" packages, except that in
this case I created a package to be installed on the *target*, not on
the *host* (which we can't modify on the autobuilder).
Ideally we would have some "devkit-cmake" like the other devkits, but
for that we would require changes to the autobuilder that I'm not sure
the maintainers are interested in, given that only a few packages use
cmake.
Regards,
--
Anderson Lizardo
OpenBossa Labs - INdT
Manaus - Brazil
> On Wednesday 26 August 2009 12:00:50 Anderson Lizardo wrote:
>> Well, we had the same problem so we produced a modified version that
>> is built using sbox's host-g++/host-gcc. This allows to use the same
>> binary both in x86 and ARMEL targets, and is a lot faster on ARMEL
>> (and does not segfault).
>
> The problem with that seems to be that you can't predict what the host is.
> For example, I use both 32-bit and 64-bit hosts. And there have, in the
> past, been libc version problems between different linux distributions.
I think you got it wrong... It will build with host-g++/host-gcc, so
it will be built with the same compiler (and linked to the same
libraries) as other internal sbox tools were compiled. Therefore, if
scratchbox works in your host, cmake compiled with host-g++ will work
too. It will not link to any host libraries, only to internal
scratchbox ones.
Unless you did not use the official sbox binaries (e.g. compiled from
sources) it should work.
If you don't know, "host-g++" is a internal scratchbox compiler used
to compile all "native" tools provided by scratchbox, that work on
both targets.
>> The "catch" is that, given that the binary is actually compiled for
>> x86, it will not run if installed on the device. It will only work on
>> Scratchbox.
>
> I'm not keen on having a host binary in a package in extras-devel. If we have
> to go down this route I think we need to find a different repository for this
> hacked cmake to live in.
That's the main reason I've been keeping it private so far. :/
>> So I ask other developers using cmake (I suppose there are not that
>> many, otherwise the problem would be reported sooner, given that cmake
>> + fremantle + ARMEL always segfaults): is it acceptable for you?
>
> I don't think there are many packages using cmake, but I think there are a
> few.
...That for some reason do not trigger the segfault on ARMEL :/
> There are two big problems I see:
>
> 1) There is not one host to build this for but several. And it has to be kept
> up to date or else we suddenly can't build some packages.
See my first comment above.
> 2) We also have to make it work in the autobuilder (how do you deal with that
> problem today?).
it will just work, because cmake compiled with host-g++ will work like
any other scratchbox internal tool.
> Alternatively, any chance we could persuade the scratchbox developers to build
> scratchbox cmake packages along with the rest of scratchbox? They could then
> be provided along with the scratchbox packages for each different
> disrtibution.
Again the approach I mentioned above is basically the same the sbox
developers use to building their "devkit" packages, except that in
this case I created a package to be installed on the *target*, not on
the *host* (which we can't modify on the autobuilder).
Ideally we would have some "devkit-cmake" like the other devkits, but
for that we would require changes to the autobuilder that I'm not sure
the maintainers are interested in, given that only a few packages use
cmake.
Regards,
--
Anderson Lizardo
OpenBossa Labs - INdT
Manaus - Brazil
the Fremantle SDK it is broken (segfault during "Check for working C
compiler:" step).
Cmake is not part of the SDK (it should be, but that is another matter). It
is in extras-devel.
Does anyone know who packaged cmake? The maintainer field is still set to
upstream but it has a "maemo" version number. Any volunteers to work out why
cmake is not working and/or to try repackaging it?
It is trivial to reproduce. Take any C program ("int main() { return 0;}"
will do), call it test.c, create a CMakeLists.txt containing:
PROJECT( test C )
and say:
cmake .
Graham