* SDK Issues
@ 2014-02-17 10:44 Jack Mitchell
2014-02-17 10:49 ` Richard Purdie
0 siblings, 1 reply; 4+ messages in thread
From: Jack Mitchell @ 2014-02-17 10:44 UTC (permalink / raw)
To: openembedded-core
I recently did a new build of my images and SDKs under master
(b188bda18690dc1af) refreshing a 3 month old build. Now everything
builds fine, but when trying to build our in house software with the
SDK, the new SDK falls over citing issues failing to link with libdl. If
I think switch back to using the old SDK, everything builds without
issue. Can anybody think of anything which might have altered the SDK in
the past few months in order to cause this to break? I have done a quick
directory diff of the 2 SDKs and nothing radically different. GCC 4.81
-> 4.82 and autotools 1.13 -> 1.14 are probably the big changes. From
what I can see the command to build the application is linking with all
the correct libraries and as it builds with previous versions I would be
surprised if this was wrong. It also seems to be struggling with the
-lcrypto libraries, but it hits the libdl issue first so it may just be
a domino effect, or there could be a significant issue with the SDK
generation.
i586-oe-linux-gcc -m32 -march=core2 -mtune=core2 -msse3 -mfpmath=sse
--sysroot=/scratch/jmitchell/oecore-sdk/1/sysroots/core2-32-oe-linux -I.
-I/scratch/jmitchell/code.git/net-snmp/../include -Wall -pipe -rdynamic
-g -Wall -Wextra -Wl,--build-id -O2 -Wall -Wstrict-prototypes
-Wwrite-strings -Wcast-qual -Wno-char-subscripts -Dlinux -o .libs/snmpd
snmpd.o -Wl,-O1 -Wl,--hash-style=gnu -Wl,--as-needed -rdynamic -rdynamic
./.libs/libucdagent.so ./.libs/libucdmibs.so -lwrap
../snmplib/.libs/libsnmp.so -lcrypto -ldl -lelf -ldl -Wl,--rpath
-Wl,/scratch/jmitchell/code.git/net-snmp/../net-snmp/usr/lib
./.libs/libucdmibs.so: undefined reference to `dlopen'
../snmplib/.libs/libsnmp.so: undefined reference to `EVP_md5'
../snmplib/.libs/libsnmp.so: undefined reference to `EVP_sha1'
../snmplib/.libs/libsnmp.so: undefined reference to `RAND_bytes'
../snmplib/.libs/libsnmp.so: undefined reference to `EVP_DigestInit'
./.libs/libucdmibs.so: undefined reference to `dlclose'
../snmplib/.libs/libsnmp.so: undefined reference to `DES_ncbc_encrypt'
../snmplib/.libs/libsnmp.so: undefined reference to `DES_cbc_encrypt'
../snmplib/.libs/libsnmp.so: undefined reference to `EVP_DigestUpdate'
../snmplib/.libs/libsnmp.so: undefined reference to `HMAC'
../snmplib/.libs/libsnmp.so: undefined reference to `DES_key_sched'
./.libs/libucdmibs.so: undefined reference to `dlerror'
./.libs/libucdmibs.so: undefined reference to `dlsym'
../snmplib/.libs/libsnmp.so: undefined reference to `EVP_DigestFinal'
Any light shed would be much appreciated!
Cheers,
--
Jack Mitchell (jack@embed.me.uk)
Embedded Systems Engineer
Cambridgeshire, UK
http://www.embed.me.uk
--
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: SDK Issues
2014-02-17 10:44 SDK Issues Jack Mitchell
@ 2014-02-17 10:49 ` Richard Purdie
2014-02-17 11:08 ` Jack Mitchell
0 siblings, 1 reply; 4+ messages in thread
From: Richard Purdie @ 2014-02-17 10:49 UTC (permalink / raw)
To: ml; +Cc: openembedded-core
On Mon, 2014-02-17 at 10:44 +0000, Jack Mitchell wrote:
> I recently did a new build of my images and SDKs under master
> (b188bda18690dc1af) refreshing a 3 month old build. Now everything
> builds fine, but when trying to build our in house software with the
> SDK, the new SDK falls over citing issues failing to link with libdl. If
> I think switch back to using the old SDK, everything builds without
> issue. Can anybody think of anything which might have altered the SDK in
> the past few months in order to cause this to break? I have done a quick
> directory diff of the 2 SDKs and nothing radically different. GCC 4.81
> -> 4.82 and autotools 1.13 -> 1.14 are probably the big changes. From
> what I can see the command to build the application is linking with all
> the correct libraries and as it builds with previous versions I would be
> surprised if this was wrong. It also seems to be struggling with the
> -lcrypto libraries, but it hits the libdl issue first so it may just be
> a domino effect, or there could be a significant issue with the SDK
> generation.
>
> i586-oe-linux-gcc -m32 -march=core2 -mtune=core2 -msse3 -mfpmath=sse
> --sysroot=/scratch/jmitchell/oecore-sdk/1/sysroots/core2-32-oe-linux -I.
> -I/scratch/jmitchell/code.git/net-snmp/../include -Wall -pipe -rdynamic
> -g -Wall -Wextra -Wl,--build-id -O2 -Wall -Wstrict-prototypes
> -Wwrite-strings -Wcast-qual -Wno-char-subscripts -Dlinux -o .libs/snmpd
> snmpd.o -Wl,-O1 -Wl,--hash-style=gnu -Wl,--as-needed -rdynamic -rdynamic
> ./.libs/libucdagent.so ./.libs/libucdmibs.so -lwrap
> ../snmplib/.libs/libsnmp.so -lcrypto -ldl -lelf -ldl -Wl,--rpath
> -Wl,/scratch/jmitchell/code.git/net-snmp/../net-snmp/usr/lib
> ./.libs/libucdmibs.so: undefined reference to `dlopen'
> ../snmplib/.libs/libsnmp.so: undefined reference to `EVP_md5'
> ../snmplib/.libs/libsnmp.so: undefined reference to `EVP_sha1'
> ../snmplib/.libs/libsnmp.so: undefined reference to `RAND_bytes'
> ../snmplib/.libs/libsnmp.so: undefined reference to `EVP_DigestInit'
> ./.libs/libucdmibs.so: undefined reference to `dlclose'
> ../snmplib/.libs/libsnmp.so: undefined reference to `DES_ncbc_encrypt'
> ../snmplib/.libs/libsnmp.so: undefined reference to `DES_cbc_encrypt'
> ../snmplib/.libs/libsnmp.so: undefined reference to `EVP_DigestUpdate'
> ../snmplib/.libs/libsnmp.so: undefined reference to `HMAC'
> ../snmplib/.libs/libsnmp.so: undefined reference to `DES_key_sched'
> ./.libs/libucdmibs.so: undefined reference to `dlerror'
> ./.libs/libucdmibs.so: undefined reference to `dlsym'
> ../snmplib/.libs/libsnmp.so: undefined reference to `EVP_DigestFinal'
>
> Any light shed would be much appreciated!
Binutils changed and we did see some occasional link issues with that.
You could try the command without -Wl,--as-needed. If that helps, you
have a library ordering issue which the new stricter binutils picked up.
I'm just guessing mind but its worth a try...
Cheers,
Richard
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: SDK Issues
2014-02-17 10:49 ` Richard Purdie
@ 2014-02-17 11:08 ` Jack Mitchell
2014-02-17 11:14 ` Burton, Ross
0 siblings, 1 reply; 4+ messages in thread
From: Jack Mitchell @ 2014-02-17 11:08 UTC (permalink / raw)
To: Richard Purdie; +Cc: openembedded-core
On 17/02/14 10:49, Richard Purdie wrote:
> On Mon, 2014-02-17 at 10:44 +0000, Jack Mitchell wrote:
>> I recently did a new build of my images and SDKs under master
>> (b188bda18690dc1af) refreshing a 3 month old build. Now everything
>> builds fine, but when trying to build our in house software with the
>> SDK, the new SDK falls over citing issues failing to link with libdl. If
>> I think switch back to using the old SDK, everything builds without
>> issue. Can anybody think of anything which might have altered the SDK in
>> the past few months in order to cause this to break? I have done a quick
>> directory diff of the 2 SDKs and nothing radically different. GCC 4.81
>> -> 4.82 and autotools 1.13 -> 1.14 are probably the big changes. From
>> what I can see the command to build the application is linking with all
>> the correct libraries and as it builds with previous versions I would be
>> surprised if this was wrong. It also seems to be struggling with the
>> -lcrypto libraries, but it hits the libdl issue first so it may just be
>> a domino effect, or there could be a significant issue with the SDK
>> generation.
>>
>> i586-oe-linux-gcc -m32 -march=core2 -mtune=core2 -msse3 -mfpmath=sse
>> --sysroot=/scratch/jmitchell/oecore-sdk/1/sysroots/core2-32-oe-linux -I.
>> -I/scratch/jmitchell/code.git/net-snmp/../include -Wall -pipe -rdynamic
>> -g -Wall -Wextra -Wl,--build-id -O2 -Wall -Wstrict-prototypes
>> -Wwrite-strings -Wcast-qual -Wno-char-subscripts -Dlinux -o .libs/snmpd
>> snmpd.o -Wl,-O1 -Wl,--hash-style=gnu -Wl,--as-needed -rdynamic -rdynamic
>> ./.libs/libucdagent.so ./.libs/libucdmibs.so -lwrap
>> ../snmplib/.libs/libsnmp.so -lcrypto -ldl -lelf -ldl -Wl,--rpath
>> -Wl,/scratch/jmitchell/code.git/net-snmp/../net-snmp/usr/lib
>> ./.libs/libucdmibs.so: undefined reference to `dlopen'
>> ../snmplib/.libs/libsnmp.so: undefined reference to `EVP_md5'
>> ../snmplib/.libs/libsnmp.so: undefined reference to `EVP_sha1'
>> ../snmplib/.libs/libsnmp.so: undefined reference to `RAND_bytes'
>> ../snmplib/.libs/libsnmp.so: undefined reference to `EVP_DigestInit'
>> ./.libs/libucdmibs.so: undefined reference to `dlclose'
>> ../snmplib/.libs/libsnmp.so: undefined reference to `DES_ncbc_encrypt'
>> ../snmplib/.libs/libsnmp.so: undefined reference to `DES_cbc_encrypt'
>> ../snmplib/.libs/libsnmp.so: undefined reference to `EVP_DigestUpdate'
>> ../snmplib/.libs/libsnmp.so: undefined reference to `HMAC'
>> ../snmplib/.libs/libsnmp.so: undefined reference to `DES_key_sched'
>> ./.libs/libucdmibs.so: undefined reference to `dlerror'
>> ./.libs/libucdmibs.so: undefined reference to `dlsym'
>> ../snmplib/.libs/libsnmp.so: undefined reference to `EVP_DigestFinal'
>>
>> Any light shed would be much appreciated!
> Binutils changed and we did see some occasional link issues with that.
> You could try the command without -Wl,--as-needed. If that helps, you
> have a library ordering issue which the new stricter binutils picked up.
>
> I'm just guessing mind but its worth a try...
>
> Cheers,
>
> Richard
>
Good shout, that seems to allow it to build; I didn't even realise
ordering of linker libs could effect the build. I guess I have some
reading to go do!
Cheers RP.
--
Jack Mitchell (jack@embed.me.uk)
Embedded Systems Engineer
Cambridgeshire, UK
http://www.embed.me.uk
--
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: SDK Issues
2014-02-17 11:08 ` Jack Mitchell
@ 2014-02-17 11:14 ` Burton, Ross
0 siblings, 0 replies; 4+ messages in thread
From: Burton, Ross @ 2014-02-17 11:14 UTC (permalink / raw)
To: Jack Mitchell; +Cc: OE-core
On 17 February 2014 11:08, Jack Mitchell <ml@communistcode.co.uk> wrote:
> Good shout, that seems to allow it to build; I didn't even realise
> ordering of linker libs could effect the build. I guess I have some
> reading to go do!
Modern binutils will only link objects that are actually used, so you
need to build the links in the right order so it doesn't just ignore
your request to link to a library (as nothing uses it) for it to then
fail later (symbols not found).
Ross
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2014-02-17 11:14 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2014-02-17 10:44 SDK Issues Jack Mitchell
2014-02-17 10:49 ` Richard Purdie
2014-02-17 11:08 ` Jack Mitchell
2014-02-17 11:14 ` Burton, Ross
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.