[uClinux-dev] RE: uCLinux Shared Library Problems: BINFMT_FLAT: library 0 is younger than 1, killing init!

Mark Plowman Mark.Plowman at Vialis.nl
Fri Aug 5 05:37:01 EDT 2005


Brad,

My 2 (euro)cents...

On Friday, August 05, 2005 5:17 AM, Goodman, Brad wrote:

> I was sucessfuly able to build a uClinux stock uClinux-dist-20041215
> distribution with the pre-built
> m68k-uclinux-tools-base-gcc3.4.0-20040603 tools.

OK.


> However, when I tried to flip-on CONFIG_BINFMT_FLAT=y and
> CONFIG_BINFMT_SHARED_FLAT=y in the 2.6.x kernel (I guess what I'm
> supposed to do to get shared library support) everything went south.

Just checking:

I assume that when it was still working you had set

  CONFIG_BINFMT_FLAT=y

and that you only added:

  CONFIG_BINFMT_SHARED_FLAT=y

when you wanted to try shared library support.

If not, what format were your binaries when everything still worked?


> When I boot, I now get:
> 
> Freeing unused kernel memory: 32k freed (0xe8000 - 0xef000)
> BINFMT_FLAT: library 0 is younger than 1, killing init!
> BINFMT_FLAT: failed to load library 1, killing init!
> BINFMT_FLAT: library 0 is younger than 1, killing sh!
> BINFMT_FLAT: failed to load library 1, killing sh!
> Kernel panic - not syncing: No init found.  Try passing init= option
> to kernel. 

Haven't I seen that too!  :-(


> So being (a Linux veteran, but) new to uCLinux - I have more
> questions than I do answers about this:

When I had similar probelms I went Googling and found some helpful
rescources...

  http://www.beyondlogic.org/uClinux/bflt.htm - A good general
  article...

  http://www.ucdot.org/article.pl?sid=03/11/25/1126257 - explains how
  shared libraries work...


> 1. I assume the apps are built as an ELF format, and converted with
>    m68k-elf-elf2flt.  Is this correct?

That is my understanding.


> 2. Info on the init file shows me:
> [bkg at catbear init]$ m68k-elf-flthdr init
> init
>     Magic:        bFLT
>     Rev:          4
>     Build Date:   Thu Aug  4 00:36:26 2005
>     Entry:        0x48
>     Data Start:   0x2f00
>     Data End:     0x3270
>     BSS End:      0x14770
>     Stack Size:   0x1000
>     Reloc Start:  0x3270
>     Reloc Count:  0x1
>     Flags:        0x2 ( Has-PIC-GOT )
> 
> How can I see which libraries it is trying to [dynamically] link to?

After linking - hardly - look in the makefile.


> 3. In my romfs/lib directory, I see only:
> 
>   lib1.so  liberror.txt
>
> The lib1.so file tells me:
> 
> [bkg at catbear lib]$ m68k-elf-flthdr lib1.so
> lib1.so
>     Magic:        bFLT
>     Rev:          4
>     Build Date:   Thu Aug  4 00:27:53 2005
>     Entry:        0x1000044
>     Data Start:   0x30fe0
>     Data End:     0x35f80
>     BSS End:      0x38380
>     Stack Size:   0x0
>     Reloc Start:  0x35f80
>     Reloc Count:  0x124
>     Flags:        0x2 ( Has-PIC-GOT )

OK.  The library was built earlier (00:27:53) than the application
that was linked against it (00:36:26), so it is safe for the
application to assume that the libraries interfaces are still as they
were when the application was linked.  (If the library was newer than
the application, the library could have changed the interfaces and it
would be unsafe to run the application without first relinking against
the library.)


> 4. Is the date discrepancy between the two files what is causing the
>    problem?

My understanding is: No.

The idea is that applications should be newer than the libraries they
refer to (and if a library refers to *another* library, that the
referring library should be newer than the referred to library).

The initial error message give us the clue: "...library 0 is younger
than 1...".

Th error message (cryptically) is telling us that Library 1 is
referring *back* to the applications (which it speaks of as "library
0").  That just shouldn't occur!  There is the problem.  The question
is: Where is the bug?  Who is making library 1 refer back to the
application ("library 0")?


> 5. Shouldn't there be a lot of other libraries in this directory?

Only you can tell me.  Look in you makefile.  What are you trying to
link in?

My understanding is that the embedded libc's (uC-libc & uClibc) tend
to throw everything into one library, so it wouldn't surprise me all
that much to only see one library...

> Is this a build problem?

I don't *think* so.  I *think/feel/guess* it is a toolchain thing...


> Thanks,

My pleasure,


> Brad Goodman

Mark Plowman


My apologies for the company boilerplate: 
  
Vialis is ISO9001, VCA** en VCA-railaddendum gecertificeerd en 
lid van Astrin, HRI, IRSE, Uneto en Vexpan. 
Vialis is een VolkerWessels onderneming. 
 
DISCLAIMER: 
De informatie, verzonden met dit e-mailbericht, is uitsluitend bestemd voor de geadresseerde. Openbaarmaking, vermenigvuldiging, verspreiding en/of verstrekking aan derden is niet toegestaan. Gebruik van deze informatie door anderen dan de geadresseerde is niet toegestaan. U wordt verzocht bij onjuiste adressering de afzender direct te informeren door het bericht te retourneren. 
Dit e-mailbericht is uitsluitend informatief van aard. Vialis besteedt de grootst mogelijke zorg aan het weren, onderkennen en elimineren van virussen. Vialis aanvaardt in geen geval aansprakelijkheid voor schade in welke vorm dan ook die het directe of indirecte gevolg is van of in verband staat met het gebruik van dit e-mailbericht en de inhoud ervan. 
 
Vialis is certified for ISO9001, VCA** and VCA rail addendum, 
and a member of Astrin, HRI, IRSE, Uneto and Vexpan. 
Vialis is a VolkerWessels company. 
 
DISCLAIMER: The information sent in and with this e-mail message is exclusively intended for the party to whom it is addressed. Publication, copying, distribution and/or disclosure to third parties is expressly prohibited. Use of this information by any party other than that to whom it is addressed, is prohibited. In case of incorrect addressing, we respectfully request that you directly inform the sender, by replying to the message.This e-mail is exclusively for information only. Vialis takes all possible care to prevent, identify and eliminate electronic viruses. On no account does Vialis accept any liability whatsoever for damages in any form that may arise, directly or indirectly, as a result of opening or using this e-mail message or its contents. 
 



More information about the uClinux-dev mailing list