Trying to compile mono on target for machine crownbay

Trying to compile mono on target for machine crownbay

[autif khan]

I bitbaked core-image-sato-sdk, copied it to the target disk and tried
to build mono natively on the target machine and I got the following
error:

libtool: link: cannot find the library `=/usr/lib/libglib-2.0.la' or
unhandled argument `=/usr/lib/libglib-2.0.la'

the filesystem does have a /usr/lib/libglib-2.0.la and it seems to be valid

I am not sure why there is a leading '=' in the path. Needless to say
- mono builds fine on ubuntu, so it is unlikely (not impossible) to be
a mono build issue.

Has anyone seen anything like this with mono or some other piece of software?

Thanks

Autif

Re: Trying to compile mono on target for machine crownbay

[autif khan]

I talked to a couple of mono developers (kangaroo and vargaz) - the
consensus is that "'auto' is hosed"

I am not an expert in auto tools, I just know how to configure, make,
make install.

I get by when I need to know my way around makefiles

I am a capable C/C++ developer - please advise or point me to right resources.

Thanks

Autif

On Thu, Jan 5, 2012 at 4:52 PM, autif khan <autif.mlist@gmail.com> wrote:
> I bitbaked core-image-sato-sdk, copied it to the target disk and tried
> to build mono natively on the target machine and I got the following
> error:
>
> libtool: link: cannot find the library `=/usr/lib/libglib-2.0.la' or
> unhandled argument `=/usr/lib/libglib-2.0.la'
>
> the filesystem does have a /usr/lib/libglib-2.0.la and it seems to be valid
>
> I am not sure why there is a leading '=' in the path. Needless to say
> - mono builds fine on ubuntu, so it is unlikely (not impossible) to be
> a mono build issue.
>
> Has anyone seen anything like this with mono or some other piece of software?
>
> Thanks
>
> Autif

Re: Trying to compile mono on target for machine crownbay

[autif khan]

Here is a recipe that I using to generate a custom SDK image which I
can use to natively compile mono on the target.

require recipes-sato/images/core-image-sato-sdk.bb
IMAGE_INSTALL += "bison libtool"
PR="r0"

bison is required and I added libtool because it was being generated
by mono's autoconf (./configure) script and gave the following error:

libtool: link: cannot find the library `=/usr/lib/libglib-2.0.la' or
unhandled argument `=/usr/lib/libglib-2.0.la'

If I understand correctly, yocto has a special libtool which
understands how to handle '=/path/to/lib'

The problem is that it looks like 'libtool' is not included in the
image. I do have the libtool recipe in meta/recipes-devtools/libtool

The libtool version generated by mono was 2.2.6b

The libtoolize version in the image is 2.4 (automake 1.11.1, autoconf 2.68)

Am I doing something wrong? If not, where is the 'libtool' in the image?

Thanks

Autif

On Thu, Jan 5, 2012 at 4:59 PM, autif khan <autif.mlist@gmail.com> wrote:
> I talked to a couple of mono developers (kangaroo and vargaz) - the
> consensus is that "'auto' is hosed"
>
> I am not an expert in auto tools, I just know how to configure, make,
> make install.
>
> I get by when I need to know my way around makefiles
>
> I am a capable C/C++ developer - please advise or point me to right resources.
>
> Thanks
>
> Autif
>
> On Thu, Jan 5, 2012 at 4:52 PM, autif khan <autif.mlist@gmail.com> wrote:
>> I bitbaked core-image-sato-sdk, copied it to the target disk and tried
>> to build mono natively on the target machine and I got the following
>> error:
>>
>> libtool: link: cannot find the library `=/usr/lib/libglib-2.0.la' or
>> unhandled argument `=/usr/lib/libglib-2.0.la'
>>
>> the filesystem does have a /usr/lib/libglib-2.0.la and it seems to be valid
>>
>> I am not sure why there is a leading '=' in the path. Needless to say
>> - mono builds fine on ubuntu, so it is unlikely (not impossible) to be
>> a mono build issue.
>>
>> Has anyone seen anything like this with mono or some other piece of software?
>>
>> Thanks
>>
>> Autif

Re: Trying to compile mono on target for machine crownbay

[autif khan]

When I try to compile mono using the ADT (bitbake meta-ide-support,
source the environment file and configure, followed by make), I get
the same behavior.

libtool: link: cannot find the library `=/usr/lib/libglib-2.0.la' or
unhandled argument `=/usr/lib/libglib-2.0.la'

But then, even in this case, mono's autoconf (./configure) generated a
'libtool' instead of using the one from yocto's development
environment.

Please advise.

Thanks

Autif

On Mon, Jan 9, 2012 at 3:12 PM, autif khan <autif.mlist@gmail.com> wrote:
> Here is a recipe that I using to generate a custom SDK image which I
> can use to natively compile mono on the target.
>
> require recipes-sato/images/core-image-sato-sdk.bb
> IMAGE_INSTALL += "bison libtool"
> PR="r0"
>
> bison is required and I added libtool because it was being generated
> by mono's autoconf (./configure) script and gave the following error:
>
> libtool: link: cannot find the library `=/usr/lib/libglib-2.0.la' or
> unhandled argument `=/usr/lib/libglib-2.0.la'
>
> If I understand correctly, yocto has a special libtool which
> understands how to handle '=/path/to/lib'
>
> The problem is that it looks like 'libtool' is not included in the
> image. I do have the libtool recipe in meta/recipes-devtools/libtool
>
> The libtool version generated by mono was 2.2.6b
>
> The libtoolize version in the image is 2.4 (automake 1.11.1, autoconf 2.68)
>
> Am I doing something wrong? If not, where is the 'libtool' in the image?
>
> Thanks
>
> Autif
>
> On Thu, Jan 5, 2012 at 4:59 PM, autif khan <autif.mlist@gmail.com> wrote:
>> I talked to a couple of mono developers (kangaroo and vargaz) - the
>> consensus is that "'auto' is hosed"
>>
>> I am not an expert in auto tools, I just know how to configure, make,
>> make install.
>>
>> I get by when I need to know my way around makefiles
>>
>> I am a capable C/C++ developer - please advise or point me to right resources.
>>
>> Thanks
>>
>> Autif
>>
>> On Thu, Jan 5, 2012 at 4:52 PM, autif khan <autif.mlist@gmail.com> wrote:
>>> I bitbaked core-image-sato-sdk, copied it to the target disk and tried
>>> to build mono natively on the target machine and I got the following
>>> error:
>>>
>>> libtool: link: cannot find the library `=/usr/lib/libglib-2.0.la' or
>>> unhandled argument `=/usr/lib/libglib-2.0.la'
>>>
>>> the filesystem does have a /usr/lib/libglib-2.0.la and it seems to be valid
>>>
>>> I am not sure why there is a leading '=' in the path. Needless to say
>>> - mono builds fine on ubuntu, so it is unlikely (not impossible) to be
>>> a mono build issue.
>>>
>>> Has anyone seen anything like this with mono or some other piece of software?
>>>
>>> Thanks
>>>
>>> Autif

Re: Trying to compile mono on target for machine crownbay

[autif khan]

While googling, I found this link
(http://mashandmish.wordpress.com/2011/04/20/crossbuilding-webkit-with-a-yocto-toolchain-part-i-glib/)

Here, the author is replacing the libtool generated by autoconf
(./configure script) with the one form the sysroot. i.e.

./configure
cp /opt/poky/1.0/sysroots/i686-pokysdk-linux/usr/bin/i686-pokysdk-libtool
libtool

I did the equivalent and amazingly got the same results.

I am sure I am missing something. Just not sure what.

On Mon, Jan 9, 2012 at 3:45 PM, autif khan <autif.mlist@gmail.com> wrote:
> When I try to compile mono using the ADT (bitbake meta-ide-support,
> source the environment file and configure, followed by make), I get
> the same behavior.
>
> libtool: link: cannot find the library `=/usr/lib/libglib-2.0.la' or
> unhandled argument `=/usr/lib/libglib-2.0.la'
>
> But then, even in this case, mono's autoconf (./configure) generated a
> 'libtool' instead of using the one from yocto's development
> environment.
>
> Please advise.
>
> Thanks
>
> Autif
>
> On Mon, Jan 9, 2012 at 3:12 PM, autif khan <autif.mlist@gmail.com> wrote:
>> Here is a recipe that I using to generate a custom SDK image which I
>> can use to natively compile mono on the target.
>>
>> require recipes-sato/images/core-image-sato-sdk.bb
>> IMAGE_INSTALL += "bison libtool"
>> PR="r0"
>>
>> bison is required and I added libtool because it was being generated
>> by mono's autoconf (./configure) script and gave the following error:
>>
>> libtool: link: cannot find the library `=/usr/lib/libglib-2.0.la' or
>> unhandled argument `=/usr/lib/libglib-2.0.la'
>>
>> If I understand correctly, yocto has a special libtool which
>> understands how to handle '=/path/to/lib'
>>
>> The problem is that it looks like 'libtool' is not included in the
>> image. I do have the libtool recipe in meta/recipes-devtools/libtool
>>
>> The libtool version generated by mono was 2.2.6b
>>
>> The libtoolize version in the image is 2.4 (automake 1.11.1, autoconf 2.68)
>>
>> Am I doing something wrong? If not, where is the 'libtool' in the image?
>>
>> Thanks
>>
>> Autif
>>
>> On Thu, Jan 5, 2012 at 4:59 PM, autif khan <autif.mlist@gmail.com> wrote:
>>> I talked to a couple of mono developers (kangaroo and vargaz) - the
>>> consensus is that "'auto' is hosed"
>>>
>>> I am not an expert in auto tools, I just know how to configure, make,
>>> make install.
>>>
>>> I get by when I need to know my way around makefiles
>>>
>>> I am a capable C/C++ developer - please advise or point me to right resources.
>>>
>>> Thanks
>>>
>>> Autif
>>>
>>> On Thu, Jan 5, 2012 at 4:52 PM, autif khan <autif.mlist@gmail.com> wrote:
>>>> I bitbaked core-image-sato-sdk, copied it to the target disk and tried
>>>> to build mono natively on the target machine and I got the following
>>>> error:
>>>>
>>>> libtool: link: cannot find the library `=/usr/lib/libglib-2.0.la' or
>>>> unhandled argument `=/usr/lib/libglib-2.0.la'
>>>>
>>>> the filesystem does have a /usr/lib/libglib-2.0.la and it seems to be valid
>>>>
>>>> I am not sure why there is a leading '=' in the path. Needless to say
>>>> - mono builds fine on ubuntu, so it is unlikely (not impossible) to be
>>>> a mono build issue.
>>>>
>>>> Has anyone seen anything like this with mono or some other piece of software?
>>>>
>>>> Thanks
>>>>
>>>> Autif

Re: Trying to compile mono on target for machine crownbay

[Mark Hatle]

On 1/5/12 3:52 PM, autif khan wrote:
> I bitbaked core-image-sato-sdk, copied it to the target disk and tried
> to build mono natively on the target machine and I got the following
> error:
>
> libtool: link: cannot find the library `=/usr/lib/libglib-2.0.la' or
> unhandled argument `=/usr/lib/libglib-2.0.la'

The version of libtool you are currently using is damaged in some way.  I 
suspect the program is falling back and trying to use either a local version or 
the host-system version.

The libtool located within the OE/Poky environment understands that when a "=" 
is predicating a path, it means locate the item within the sysroot at the 
following path.  Since the error indicates it doesn't understand that concept, 
it appears that that version of libtool is broken.

Normally the autotools class will deal with this situation for you.  Simply 
inheriting autotools class usually does it.

--Mark

> the filesystem does have a /usr/lib/libglib-2.0.la and it seems to be valid
>
> I am not sure why there is a leading '=' in the path. Needless to say
> - mono builds fine on ubuntu, so it is unlikely (not impossible) to be
> a mono build issue.
>
> Has anyone seen anything like this with mono or some other piece of software?
>
> Thanks
>
> Autif
> _______________________________________________
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto

Re: Trying to compile mono on target for machine crownbay

[autif khan]

On Thu, Jan 5, 2012 at 5:17 PM, Mark Hatle <mark.hatle@windriver.com> wrote:
> On 1/5/12 3:52 PM, autif khan wrote:
>> libtool: link: cannot find the library `=/usr/lib/libglib-2.0.la' or
>> unhandled argument `=/usr/lib/libglib-2.0.la'
>
>
> The version of libtool you are currently using is damaged in some way.  I
> suspect the program is falling back and trying to use either a local version
> or the host-system version.


I am using 6.0 Edison release of yocto. Is libtool being broken a
known issue for this version?


> The libtool located within the OE/Poky environment understands that when a
> "=" is predicating a path, it means locate the item within the sysroot at
> the following path.  Since the error indicates it doesn't understand that
> concept, it appears that that version of libtool is broken.
>
> Normally the autotools class will deal with this situation for you.  Simply
> inheriting autotools class usually does it.

For now, there is no recipe for mono in yocto. There is one for a very
old version of mono on OE that I have looked at. It does not work,
when it is integrated in some layer. It fails with a somewhat
different error (included below). So I am trying to write the recipe
for mono and trying to compile it on native hardware - that would be
the first step - if I can compile it natively, then I will try to
cross compile it, and then I can try to write the recipe.

So, I do not have a sysroot to cross compile ... It is the native root
file system - the compilation happens on the target hardware.

How can I figure out what the issue is with auto tools?

Thanks

Autif

Error form mono recipe from OE:
checking for preceeding underscore in symbols... configure: error: in
`/home/autif/data/dev/yocto/koko/tmp/work/core2-poky-linux/mono-2.6.3-r0.1/mono-2.6.3':
configure: error: cannot run test program while cross compiling

Re: Trying to compile mono on target for machine crownbay

[Khem Raj]

On (05/01/12 17:36), autif khan wrote:
> On Thu, Jan 5, 2012 at 5:17 PM, Mark Hatle <mark.hatle@windriver.com> wrote:
> > On 1/5/12 3:52 PM, autif khan wrote:
> >> libtool: link: cannot find the library `=/usr/lib/libglib-2.0.la' or
> >> unhandled argument `=/usr/lib/libglib-2.0.la'
> >
> >
> > The version of libtool you are currently using is damaged in some way.  I
> > suspect the program is falling back and trying to use either a local version
> > or the host-system version.
> 
> 
> I am using 6.0 Edison release of yocto. Is libtool being broken a
> known issue for this version?
> 

nothing is broken. Its the mono package which uses older version of
libtool (pre 2.4) and its trying to link in .la files which are generated by new
libtool 2.4+

your best option is that add the mono recipe to metadata and build it
there instead of building it on target. If you want to build on target
than you have to regenerate its autotools related build configuration

best option is to get the recipes from oe.dev and use them that probably
would work out quicker for you.

-Khem

Re: Trying to compile mono on target for machine crownbay

[Evgheni Antropov]

In my case I have resolved it in another way: 

correct in Makefile for "eglib" folder SUBDIRS variables and excluded "test" 
from them values:

-----------------------------------------
egrep "SUBDIRS =" ./mono-2.10.2/build/eglib/Makefile
DIST_SUBDIRS = src test
SUBDIRS = src test
#SUBDIRS = src
#SUBDIRS = src
#SUBDIRS = src

+++++++++++++++++++++++++++++++++++++++++
egrep "SUBDIRS =" ./mono-2.10.2/build/eglib/Makefile
DIST_SUBDIRS = src
SUBDIRS = src
#SUBDIRS = src
#SUBDIRS = src
#SUBDIRS = src

"build" is my own directory where I'm compiling mono.

Re: Trying to compile mono on target for machine crownbay

[Autif Khan]

On Wed, Feb 20, 2013 at 11:30 AM, Evgheni Antropov <aidjek@gmail.com> wrote:
> In my case I have resolved it in another way:
>
> correct in Makefile for "eglib" folder SUBDIRS variables and excluded "test"
> from them values:
>
> -----------------------------------------
> egrep "SUBDIRS =" ./mono-2.10.2/build/eglib/Makefile
> DIST_SUBDIRS = src test
> SUBDIRS = src test
> #SUBDIRS = src
> #SUBDIRS = src
> #SUBDIRS = src
>
> +++++++++++++++++++++++++++++++++++++++++
> egrep "SUBDIRS =" ./mono-2.10.2/build/eglib/Makefile
> DIST_SUBDIRS = src
> SUBDIRS = src
> #SUBDIRS = src
> #SUBDIRS = src
> #SUBDIRS = src
>
> "build" is my own directory where I'm compiling mono.
>
>

Just FYI - meta-mono is available as a layer that can build mono on a
build machine (cross compilation) instead of natively compiling mono
in target device.

http://git.yoctoproject.org/cgit/cgit.cgi/meta-mono/