[ELDK] ld.so.1 needed by libpthread.so.0 not found

[Christian Ege]

Hi,
> I found the solution with the help of an offlist email response from Christian Ege, pointing me here:
> http://stackoverflow.com/questions/9095349/eldk-gcc-linker-error-in-ld-so-1
Sorry for the offlist email I hit the wrong button on my phone.
> Given my ELDK installation path and chosen platform, my solution was:
> 	cd /opt/eldk/usr/ppc-linux/lib
> 	sudo ln -s ../../../ppc_82xx/lib/ld.so.1
>
> After that, my application built fine and was roughly the same size that I expected.
>
> The same solution worked for me on SUSE 3.11.6 and on Ubuntu 12.04
Nice to here it is working. The whole discussion  raises some questions:

- What support period can I suspect from a recent ELDK?
- Are there any Long Term Yocto/ELDK releases planned?

For industrial applications life cycles of 5-10 years are not seldom.

regards,
Christian
> LTS.
>
> Thank you everyone for the help!
>
> Ed J
>
> -----Original Message-----
> From: Wolfgang Denk [mailto:wd at denx.de]
> Sent: Friday, January 24, 2014 2:24 PM
> To: Larry Baker
> Cc: Ed Jubenville; eldk at lists.denx.de
> Subject: Re: [ELDK] ld.so.1 needed by libpthread.so.0 not found
>
> Dear Larry,
>
> In message <A3052169-FDF2-4691-8C58-9D4C11072C46 at usgs.gov> you wrote:
>> I do not understand why the version of SUSE has anything to do with
>> your linker failure.  Your cross-development environment should be
>> compiling with target headers and linking with target static and
>> shared libraries only.  Those should all be contained in the ELDK
>> 3.1.1 cross-development kit -- they have nothing to do with the host
>> O/S release.  I suspect
> The ELDK 3.1.1 tools were built in March 2005 using a RedHat 7.3 based build host, with a 2.4 kernel etc.  A _lot_ of things have changed since; there is no guarantee that the old binaries will still execute correctly in the new environment - using totally different shared libraries etc.  Even if everything appears to work fine you can never be sure.
>
> For a production environment such uncertainty is not acceptable. Here you must be able to fully trust your tools.  The only feasible approach here is to run in a supported OS environment - either on a phyical or on a virtual machine.  Given that it may be difficult to run such old kernels on current hardware (for example, you may find that there are no drivers for the S-ATA controllers in your PC), it is much easier and much less maintenannce effort to set up a virtual host.
>
> Best regards,
>
> Wolfgang Denk
>