• JS Bangs (41/41) Dec 06 2007 I've got a D program that needs to link in a few C object files (from a ...
• BCS (7/28) Dec 06 2007 I think that it is here "-L-lfl" this is assuming that libfl.a is from f...
• jaspax (5/10) Dec 10 2007 That turned out to be the case. Once I stopped linking to -lfl the probl...

JS Bangs <jaspax gmail.com> writes:

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?

BCS <ao pathlink.com> writes:

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)

jaspax <jaspax gmail.com> writes:

== 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.)