Mail Archives: djgpp/1997/10/31/01:46:40
the way you should do your program, is that every file can be compiled into
o file separately, with extern functions prototyped as such at the top...
then do
gcc -o bluh.exe main.o foo.o bluh.o truh.0 -lalleg
this will include allegro as a lib, which might be the problem as welll
it is NOT a bug in anything.... just a confusing aspect of context...
--
Alexey.
TASTATBC: There Ain't Such Thing As The Best Code.
Robert Darmochwa³ <kacmajor AT polbox DOT com> wrote in article
<199710301806 DOT TAA02169 AT free DOT polbox DOT pl>...
> 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
>
>
> some uforulz() function from file foo.c calls allegoro's func
> play_memory_fli like:
>
> uforulz()
> {
> play_memory_fli(lameani,screen,0,NULL);
> }
>
> 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...
>
> for example :
>
> main()
> {
> uforulz();
> return;
> } //gcc says unresolved external in file foo.c func
> uforulz()
>
> main()
> {
> uforulz();
> return;
> play_memory_fli(blah,blah,blah,blah)
> } // 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....
>
>
>
>
>
>
>
>
>
>
- Raw text -