Date: Thu, 30 Oct 1997 20:24:02 -0800 (PST)
Message-Id: <199710310424.UAA26536@adit.ap.net>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
To: "=?ISO-8859-2?Q?Robert_Darmochwa=B3?=" <kacmajor AT polbox DOT com>,
        "DJGPP Mailing List" <djgpp AT delorie DOT com>
From: Nate Eldredge <eldredge AT ap DOT net>
Subject: Re: 99% sure bug.But i dunno if it's allegro or djgpp's fault..
Precedence: bulk

At 07:10  10/30/1997 +0100, =?ISO-8859-2?Q?Robert_Darmochwa=B3?= wrote:
>So here it is ..
>my frogram has  for exemple 3 files.(accurately it has much more, but it's
>a example)
>
>let it be:
>main.c
>foo.c
>liballeg.a
>[snipped]
>everything seems t be ok, but when i ling gcc -g main.c liballeg.a foo.o,
>after compiling foo.c off course (gcc -c foo.c) 
>gcc says: unresolved external play_memory_fli...
>
>and here's most exciting part:
>
>when i add a line to my main() function, stored in file main.c
>which calls play_memory_fli too, it compiles then...
>[snipped]
>}   // in this case gcc compiles correctly!! notice that play_memory_fli 
> is after return, so this is a dead code...but without that gcc cannot 
>find P_M_F function at all....
This is not a bug. GNU ld, DJGPP's linker, is a one-pass linker. It resolves
externals in files in the order they are specified. So when you specify:
main.c liballeg.a foo.o

First it looks through main.o (after it's compiled) for any externals. Then
it looks through liballeg.a and resolves all the externals it has seen so
far. It has not yet seen the reference to play_memory_fli, and so it doesn't
link it. Now it gets to foo.o. It finds an unresolved external:
play_memory_fli. But there are no more files to link, so it ends up not
being found, and it complains.

The solution: Use this order
main.c foo.o liballeg.a

Then all the references to Allegro symbols will accumulate till the end, and
be found then.

Nate Eldredge
eldredge AT ap DOT net