I've got a D program that needs to link in a few C object files (from a parser written in bison/flex). It builds just fine, but when I run the program my D main() never gets called. Instead a main in something called libmain.o gets called and exits.

Building:
gcc -c -ggdb -g3 -O0 -D_GNU_SOURCE=1 phonix.lex.c -o objs/phonix.lex.o
gcc -c -ggdb -g3 -O0 -D_GNU_SOURCE=1 phonix.tab.c -o objs/phonix.tab.o
gcc -ggdb -g3 -O0 -D_GNU_SOURCE=1 -o parser-test objs/phonix.lex.o objs/phonix.tab.o parser.c -lfl
dmd -debug -g -odobjs -ofphonix features.d parser.d phonix.d -Lobjs/phonix.lex.o -Lobjs/phonix.tab.o -L-lfl -L-v
gcc objs/features.o objs/parser.o objs/phonix.o -o phonix -g -m32 -Xlinker objs/phonix.lex.o -Xlinker objs/phonix.tab.o -lfl -Xlinker -v -lphobos -lpthread -lm
collect2 version 4.1.2 20061115 (prerelease) (Debian 4.1.1-21) (i386 Linux/ELF)
/usr/bin/ld --eh-frame-hdr -m elf_i386 -dynamic-linker /lib/ld-linux.so.2 -o phonix /usr/lib/gcc/i486-linux-gnu/4.1.2/../../../../lib/crt1.o /usr/lib/gcc/i486-linux-gnu/4.1.2/../../../../lib/crti.o /usr/lib/gcc/i486-linux-gnu/4.1.2/crtbegin.o -L/usr/lib/gcc/i486-linux-gnu/4.1.2 -L/usr/lib/gcc/i486-linux-gnu/4.1.2 -L/usr/lib/gcc/i486-linux-gnu/4.1.2/../../../../lib -L/lib/../lib -L/usr/lib/../lib objs/features.o objs/parser.o objs/phonix.o objs/phonix.lex.o objs/phonix.tab.o -lfl -v -lphobos -lpthread -lm -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed /usr/lib/gcc/i486-linux-gnu/4.1.2/crtend.o /usr/lib/gcc/i486-linux-gnu/4.1.2/../../../../lib/crtn.o
GNU ld version 2.17 Debian GNU/Linux

Debugging:
GNU gdb 6.4.90-debian

(gdb) b main
Breakpoint 1 at 0x804d390: file libmain.c, line 30.
(gdb) run < testfile
Starting program: /home/jaspax/dsim/phonix/phonix < testfile

Breakpoint 1, main () at libmain.c:30
30      libmain.c: No such file or directory.
        in libmain.c
(gdb) disassemble
Dump of assembler code for function main:
0x0804d370 <main+0>:    lea    0x4(%esp),%ecx
0x0804d374 <main+4>:    and    $0xfffffff0,%esp
0x0804d377 <main+7>:    pushl  0xfffffffc(%ecx)
0x0804d37a <main+10>:   push   %ebp
0x0804d37b <main+11>:   mov    %esp,%ebp
0x0804d37d <main+13>:   push   %ebx
0x0804d37e <main+14>:   call   0x804d3a0 <__i686.get_pc_thunk.bx>
0x0804d383 <main+19>:   add    $0x17885,%ebx
0x0804d389 <main+25>:   push   %ecx
0x0804d38a <main+26>:   lea    0x0(%esi),%esi
0x0804d390 <main+32>:   call   0x8049d74 <yylex>
0x0804d395 <main+37>:   test   %eax,%eax
0x0804d397 <main+39>:   jne    0x804d390 <main+32>
0x0804d399 <main+41>:   pop    %ecx
0x0804d39a <main+42>:   pop    %ebx
0x0804d39b <main+43>:   pop    %ebp
0x0804d39c <main+44>:   lea    0xfffffffc(%ecx),%esp
0x0804d39f <main+47>:   ret
End of assembler dump.

As you can see, for some reason there's this file that calls my yylex() in a loop, then exits. Where did this come from and how can I make it go away?

Reply to JS,

> I've got a D program that needs to link in a few C object files (from
> a parser written in bison/flex). It builds just fine, but when I run
> the program my D main() never gets called. Instead a main in something
> called libmain.o gets called and exits.
> 
> Building:
> 
> gcc -c -ggdb -g3 -O0 -D_GNU_SOURCE=1 phonix.lex.c -o objs/phonix.lex.o
> 
> gcc -c -ggdb -g3 -O0 -D_GNU_SOURCE=1 phonix.tab.c -o objs/phonix.tab.o
> 
> gcc -ggdb -g3 -O0 -D_GNU_SOURCE=1 -o parser-test objs/phonix.lex.o
> objs/phonix.tab.o parser.c -lfl
> 
> dmd -debug -g -odobjs -ofphonix features.d parser.d phonix.d
> -Lobjs/phonix.lex.o -Lobjs/phonix.tab.o -L-lfl -L-v
>
[...]
> 
> As you can see, for some reason there's this file that calls my
> yylex() in a loop, then exits. Where did this come from and how can I
> make it go away?
> 

I think that it is here "-L-lfl" this is assuming that libfl.a is from flex. My suggestion is to replace the d stuff with a c hello world and get that running. Then get the D version working. I would also recommend that you compile and link the D code in 2 steps. To do that run gcc as you would for a normal link but also link with libphobos (or something similar for tango)

== Quote from BCS (ao@pathlink.com)'s article
> I think that it is here "-L-lfl" this is assuming that libfl.a is from flex. My suggestion is to replace the d stuff with a c hello world and get that running. Then get the D version working. I would also recommend that you compile and link the D code in 2 steps. To do that run gcc as you would for a normal link but also link with libphobos (or something similar for tango)

That turned out to be the case. Once I stopped linking to -lfl the problem went away, and the -lfl turned out to not be needed in D anyway.

(I actually already had a working example in C. This problem came up as I was trying to bootstrap to the full D example.)