[coldfire-gnu-discuss] Usage of shared libraries

[Jate Sujjavanich]

I attempted to create a shared library according to the new method on pg
11 of the guide. I believe that the endianness of the data_end and
data_start in the flat_hdr is causing a large negative size (0xffffffe4
or something). So I abandoned that method and tried the old way.

I've tried using the old/uClibc method to get this working.
Unfortunately, I am getting an "Illegal Instruction" on the load of the
flat file. Do you have a working example for a small "hello world"
shared library using either the new or old method? Thanks.

- Jate

-----Original Message-----
From: Carlos O'Donell [mailto:carlos at codesourcery.com] 
Sent: Thursday, August 30, 2007 4:24 PM
To: Jate Sujjavanich
Cc: coldfire-gnu-discuss at codesourcery.com
Subject: Re: [coldfire-gnu-discuss] Usage of shared libraries

On Thu, Aug 30, 2007 at 03:02:31PM -0400, Jate Sujjavanich wrote:
> What I am trying to do now is create a "hello world" shared library.
> Using options as recommended on uCdot.org creates a library of size 
> mshared-library-id * 16 MB. I am looking for the new recommended way 
> of creating one for this toolchain.

The recommended way to create shared libraries for CodeSourcery's
Sourcery G++ toolchains is documented in the "Getting Started" guide.
More specifically Chpater 3, Section 2, "Shared Libraries" page 10.
 
> I am also having some issues with an application that is threaded 
> using pthreads. It seems that the errno is not being passed from the 
> kernel to the uClibc side of the system call. In my case, the mkfifo 
> (mknod) does return a -1, but the errno on the application side is 
> always a 0. I have a feeling this may be fixed in the latest uClibc.
Does anyone know?

As far as I know this is not fixed in the latest uClibc. Please see
Chapter 3, Section 2.4, "Symbol Binding." uClibc doesn't follow normal
ELF symbol resolution and the threads errno cannot be updated. 

The simplest workaround is not to use shared libraries and pthreads.

Cheers,
Carlos.
--
Carlos O'Donell
CodeSourcery
carlos at codesourcery.com
(650) 331-3385 x716



 
 
************************************************************************
************
This footnote confirms that this email message has been scanned by
PineApp Mail-SeCure for the presence of malicious code, vandals &
computer viruses.
************************************************************************
************