Ticket #1027 (closed defect: fixed)
libgobject compiled with wrong toolchain
| Reported by: | jeremy-list | Owned by: | TAsn |
|---|---|---|---|
| Priority: | major | Milestone: | wishlist |
| Component: | Other | Version: | SHR-unstable |
| Keywords: | Cc: |
Description
Until I bricked my phone a couple of hours ago I had a few small programs written in vala on my phone (nothing worth putting in a feed, but useful for the courses I'm taking at university). Unfortunately I've run into a few issues with libgobject. The version in the feed segfaults when any of its methods are called by a program compiled using arm-oe-linux-gnueabi-gcc. The same source code works fine if it's compiled using arm-angstrom-linux-gnueabi-gcc but that code segfaults when it calls any gtk methods. It is possible to get a perfectly functional binary by sorting all the code into different files for gtk and gobject calls, compiling them to .o files, and linking them together. But that solution is extremely sub-optimal.
Change History
comment:1 Changed 23 months ago by Heinervdm
- Owner changed from ainulindale to TAsn
- Component changed from SHR Image to Other
comment:2 follow-up: ↓ 4 Changed 23 months ago by jeremy-list
that isn't quite what I meant: the version of libgobject that's included with SHR appears to have been compiled using a slightly incompatible toolchain! If someone is willing to compile it using bitbake instead (I'd do it except I just moved house and have no internet at hone yet) this bug would be fixed.
comment:4 in reply to: ↑ 2 Changed 22 months ago by TAsn
Replying to jeremy-list:
that isn't quite what I meant: the version of libgobject that's included with SHR appears to have been compiled using a slightly incompatible toolchain! If someone is willing to compile it using bitbake instead (I'd do it except I just moved house and have no internet at hone yet) this bug would be fixed.
We compile it using bitbake, the same why like we compile everything else.
comment:5 Changed 22 months ago by jeremy-list
that's weird: if I compile something using a third party toolchain then I get no issues at all with gobject, just a lot of issues with most other libraries I might want to use. But if I use the toolchain I get on the phone by running 'opkg install gcc-symlinks binutils' or the one that gets set up by bitbake I get a segfault whenever I call any method in libgobject!
We curently have no toolchain. One would have to donwload the current one every week, because of incompatible changes comming form E and other librarys.
The recommended way to build a programm for SHR is using bitbake, that way you have always the current libarys and compiler on your buildhost.
And as we can't fix bugs in 3. party toolchains the only thing i can say about this ticket is, that it's invalid.