svn fetcher crashes

svn fetcher crashes

[matti kaasinen]

[-- Attachment #1: Type: text/plain, Size: 770 bytes --]

Hello!

I tried to upgrade poky from fido to krogoth. Recipes that used to work
before are now crashing. I get long listing of warnings telling "Exception
during build_dependencies for S". At the end will come:
svn: /CPR3/sysroots/x86_64-linux/usr/bin/../lib/./././libssl.so.1.0.0:
version `OPENSSL_1.0.0' not found (required by
/CPR3/sysroots/x86_64-linux/usr/bin/../lib/././libserf-1.so.1)
svn: /CPR3/sysroots/x86_64-linux/usr/bin/../lib/./././libcrypto.so.1.0.0:
version `OPENSSL_1.0.0' not found (required by
/CPR3/sysroots/x86_64-linux/usr/bin/../lib/././libserf-1.so.1)

Location these error messages are referring has following libssl modules:
libssl3.so
libssl.a
libssl.so
libssl.so.1.0.0
ssl

Any help really appreciated!!

Thanks,
Matti

[-- Attachment #2: Type: text/html, Size: 968 bytes --]

Re: svn fetcher crashes

[Bas Mevissen]

On 01/11/16 15:32, matti kaasinen wrote:
> Hello!
>
> I tried to upgrade poky from fido to krogoth.

It might be wise to wait a few days and start from the upcoming morthy 
release.

> Recipes that used to work
> before are now crashing. I get long listing of warnings telling
> "Exception during build_dependencies for S". At the end will come:
> svn: /CPR3/sysroots/x86_64-linux/usr/bin/../lib/./././libssl.so.1.0.0:
> version `OPENSSL_1.0.0' not found (required by
> /CPR3/sysroots/x86_64-linux/usr/bin/../lib/././libserf-1.so.1)
> svn:
> /CPR3/sysroots/x86_64-linux/usr/bin/../lib/./././libcrypto.so.1.0.0:
> version `OPENSSL_1.0.0' not found (required by
> /CPR3/sysroots/x86_64-linux/usr/bin/../lib/././libserf-1.so.1)
>

Did you start with a clean work area?

Post the output of a single package, including the logs

> Location these error messages are referring has following libssl modules:
> libssl3.so
> libssl.a
> libssl.so
> libssl.so.1.0.0
> ssl
>

That is something we will probably sort out in the process. Guess the 
current openssl is 1.0.2 and the old 1.0.0 is no longer in your staging.


-- 
Bas.

Re: svn fetcher crashes

[matti kaasinen]

[-- Attachment #1: Type: text/plain, Size: 1569 bytes --]

2016-11-01 19:05 GMT+02:00 Bas Mevissen <abuse@basmevissen.nl>:

> It might be wise to wait a few days and start from the upcoming morthy
> release.
>
Unfortunately I need meta-ti layer and they support only every other main
version. Their latest release is krogoth and they are skipping morthy. In
fact, some update (source revision 4.1.17 -> 4.1.18)  broke kernel that is
why I tried to make this upgrade instead of trying to fix kernel.

>
> Recipes that used to work
>> before are now crashing. I get long listing of warnings telling
>> "Exception during build_dependencies for S". At the end will come:
>> svn: /CPR3/sysroots/x86_64-linux/usr/bin/../lib/./././libssl.so.1.0.0:
>> version `OPENSSL_1.0.0' not found (required by
>> /CPR3/sysroots/x86_64-linux/usr/bin/../lib/././libserf-1.so.1)
>> svn:
>> /CPR3/sysroots/x86_64-linux/usr/bin/../lib/./././libcrypto.so.1.0.0:
>> version `OPENSSL_1.0.0' not found (required by
>> /CPR3/sysroots/x86_64-linux/usr/bin/../lib/././libserf-1.so.1)
>>
>>
> Did you start with a clean work area?
>
No, I did not, I deleted SSTATE_DIR, though. I'll clean it tomorrow.

>
> Post the output of a single package, including the logs.
>
Ok, I'll do it tomorrow, if problems don't vanish.

>
> Location these error messages are referring has following libssl modules:
>> libssl3.so
>> libssl.a
>> libssl.so
>> libssl.so.1.0.0
>> ssl
>>
>>
> That is something we will probably sort out in the process. Guess the
> current openssl is 1.0.2 and the old 1.0.0 is no longer in your staging.
>

[-- Attachment #2: Type: text/html, Size: 3124 bytes --]

Re: svn fetcher crashes

[Bas Mevissen]

On 01/11/16 18:49, matti kaasinen wrote:
>
> 2016-11-01 19:05 GMT+02:00 Bas Mevissen <abuse@basmevissen.nl
> <mailto:abuse@basmevissen.nl>>:
>
>     It might be wise to wait a few days and start from the upcoming
>     morthy release.
>
> Unfortunately I need meta-ti layer and they support only every other
> main version. Their latest release is krogoth and they are skipping
> morthy. In fact, some update (source revision 4.1.17 -> 4.1.18)  broke
> kernel that is why I tried to make this upgrade instead of trying to fix
> kernel.
>

Too bad.

Be aware that from Krogoth to Morpy, quite some GCC6 host compiler fixes 
were added. So keep your build host on a distro with GCC 5.x.

>     Did you start with a clean work area?
>
> No, I did not, I deleted SSTATE_DIR, though. I'll clean it tomorrow.
>

OK, keep us posted.

-- 
Bas.

Re: svn fetcher crashes

[matti kaasinen]

[-- Attachment #1: Type: text/plain, Size: 1840 bytes --]

2016-11-01 23:40 GMT+02:00 Bas Mevissen <abuse@basmevissen.nl>:

> On 01/11/16 18:49, matti kaasinen wrote:
>
>>
>> 2016-11-01 19:05 GMT+02:00 Bas Mevissen <abuse@basmevissen.nl
>> <mailto:abuse@basmevissen.nl>>:
>>
>>     It might be wise to wait a few days and start from the upcoming
>>     morthy release.
>>
>> Unfortunately I need meta-ti layer and they support only every other
>> main version. Their latest release is krogoth and they are skipping
>> morthy. In fact, some update (source revision 4.1.17 -> 4.1.18)  broke
>> kernel that is why I tried to make this upgrade instead of trying to fix
>> kernel.
>>
>>
> Too bad.
>
> Be aware that from Krogoth to Morpy, quite some GCC6 host compiler fixes
> were added. So keep your build host on a distro with GCC 5.x.
>

 Version seems to be arm-poky-linux-gnueabi-gcc (GCC) 5.3.0, but something
strange there is now compared to fido compilation.(see below)

>
>     Did you start with a clean work area?
>>
>> No, I did not, I deleted SSTATE_DIR, though. I'll clean it tomorrow.
>>
>>
> OK, keep us posted.

Clearing workspace helped with that issue and I got new one(s): For the
firstly: u-boot does not compile with my patches, but that is what I can
dig. More harder one is that gcc does not produce symbols with -fpic or
-FPIC as they did with fido - well with my recipes, anyway.

Compiler commands in these utiity procedures to be packed to library are:
    ${CC} -c -fpic ${S}/mname.c

When i test object (mname.o) compiled using command:
objdump -t objname.o

I'll get only a message telling that file format is elf32-little and no
symbols in symbol table.
Fido compilation with same compiler options give same file format, but also
symbols. Should add more compiler options or what else am I doing wrong?

Thanks,
Matti

[-- Attachment #2: Type: text/html, Size: 3024 bytes --]

Re: svn fetcher crashes

[Bas Mevissen]

On November 2, 2016 3:13:47 PM GMT+01:00, matti kaasinen <matti.kaasinen@gmail.com> wrote:
>2016-11-01 23:40 GMT+02:00 Bas Mevissen <abuse@basmevissen.nl>:
>
>> On 01/11/16 18:49, matti kaasinen wrote:
>>
>>>
>>> 2016-11-01 19:05 GMT+02:00 Bas Mevissen <abuse@basmevissen.nl
>>> <mailto:abuse@basmevissen.nl>>:
>>>
>>>     It might be wise to wait a few days and start from the upcoming
>>>     morthy release.
>>>
>>> Unfortunately I need meta-ti layer and they support only every other
>>> main version. Their latest release is krogoth and they are skipping
>>> morthy. In fact, some update (source revision 4.1.17 -> 4.1.18) 
>broke
>>> kernel that is why I tried to make this upgrade instead of trying to
>fix
>>> kernel.
>>>
>>>
>> Too bad.
>>
>> Be aware that from Krogoth to Morpy, quite some GCC6 host compiler
>fixes
>> were added. So keep your build host on a distro with GCC 5.x.
>>
>
>Version seems to be arm-poky-linux-gnueabi-gcc (GCC) 5.3.0, but
>something
>strange there is now compared to fido compilation.(see below)
>


I meant the gcc of the host, the native compiler. Make sure you run a distro that uses gcc 5.x and not 6.x with Krogoth.


-- 
Bas.

Re: svn fetcher crashes

[matti kaasinen]

[-- Attachment #1: Type: text/plain, Size: 635 bytes --]

2016-11-02 22:02 GMT+02:00 Bas Mevissen <abuse@basmevissen.nl>:

> >> Be aware that from Krogoth to Morpy, quite some GCC6 host compiler
> >fixes
> >> were added. So keep your build host on a distro with GCC 5.x.
> >>
> >
> >Version seems to be arm-poky-linux-gnueabi-gcc (GCC) 5.3.0, but
> >something
> >strange there is now compared to fido compilation.(see below)
> >
>
>
> I meant the gcc of the host, the native compiler. Make sure you run a
> distro that uses gcc 5.x and not 6.x with Krogoth.

gcc seems to be:
gcc --version
gcc (Ubuntu 4.8.4-2ubuntu1~14.04.3) 4.8.4

So, it should not be too fresh anyway!

[-- Attachment #2: Type: text/html, Size: 1065 bytes --]

Re: svn fetcher crashes

[matti kaasinen]

[-- Attachment #1: Type: text/plain, Size: 1764 bytes --]

This issue is a bit off-the-original-topic, but as I found reason/solution
to this other problem, please find it below:

2016-11-02 16:13 GMT+02:00 matti kaasinen <matti.kaasinen@gmail.com>:

> Clearing workspace helped with that issue and I got new one(s): For the
> firstly: u-boot does not compile with my patches, but that is what I can
> dig. More harder one is that gcc does not produce symbols with -fpic or
> -FPIC as they did with fido - well with my recipes, anyway.
>
> Compiler commands in these utiity procedures to be packed to library are:
>     ${CC} -c -fpic ${S}/mname.c
>
> When i test object (mname.o) compiled using command:
> objdump -t objname.o
>
> I'll get only a message telling that file format is elf32-little and no
> symbols in symbol table.
> Fido compilation with same compiler options give same file format, but
> also symbols. Should add more compiler options or what else am I doing
> wrong?
>
In fact it did not matter if there was -fpic or not. Binary in working
folder was ok. However, file in staging directory was not.

File commands gave slightly different results in those two locations:
working directory:
objname.o: ELF 32-bit LSB  relocatable, ARM, EABI5 version 1 (SYSV), not
stripped
staging directory:
objname.o: ELF 32-bit LSB  relocatable, ARM, EABI5 version 1 (SYSV),
stripped

So, the reason:
The command I used in my recipe to copy object to staging directory was:
install -m 0755 ${S}/objname.o ${D}${STAGE}/

It seems that install command in bitbake recipe has changed since fido
version. Execute acl triggered something to make stripping. However,
stripping does not happen if I remove execute acl like on the line below:
install -m 0644 ${S}/objname.o ${D}${STAGE}/

[-- Attachment #2: Type: text/html, Size: 2347 bytes --]