Sam Steingold wrote: > /home/sds/src/clisp/current/build-gxx-g/../src/time.d:75: undefined reference > to `rpl_gettimeofday(timeval*, void*)' > time.o: In function `C_sleep()': > /home/sds/src/clisp/current/build-gxx-g/../src/time.d:503: undefined > reference to `rpl_gettimeofday(timeval*, void*)' > /home/sds/src/clisp/current/build-gxx-g/../src/time.d:529: undefined > reference to `rpl_gettimeofday(timeval*, void*)' > collect2: ld returned 1 exit status > > nm gllib/gettimeofday.o > U gettimeofday > 0000000000000000 T rpl_gettimeofday > > note that the error message lists the arglist of rpl_gettimeofday.
That means that the function had C++ linkage and hence its assembler name was mangled to encode its type, and the linker is helpfully demangling the name for display purposes. If you run "nm time.o" I bet you'll see the symbol's real asmname shown as "_Z16rpl_gettimeofdayP7timevalPv" or similar, which explains why it can't be resolved by the symbol in gettimeofday.o with C linkage. > when I remove gllib/uniwidth/width.o from the command line, I get > > charstrg.o: In function `char_width(chart)': > /home/sds/src/clisp/current/build-gxx-g/../src/charstrg.d:324: undefined > reference to `uc_width' > > without the arglist of uc_width. The uniwidth.h header declares uc_width in an extern "C" block to ensure it has C linkage when built with a C++ compiler. > any ideas? It looks like lib/sys_time.in.h needs the same 'extern "C"' treatment. Brian
