Re: [Tinycc-devel] Re: Naming confusion

[grischka]

Christoph Gärtner wrote:
> As far as my google-fu can tell, the gcc low-level runtime-library is 
> called "libgcc.a"[1]; however, the files "libgcc1.c", "libgcc2.c" and 
> "libgcc2.a" are part of its build process[2].
>
> Similarly, the corresponding library for the Portable C Compiler is 
> called "libpcc.a". If we're aiming for consistency, we'd actually have 
> to drop the 1 and rename the current "libtcc.a" to something else.

It is just that there is no something else that is more natural
than "libtcc" for "tcc" built as a library.

>  > tcc_set_lib_path() sets tcc_lib_path which is where tcc finds:
>  > 1) libtcc1.a
>  > 2) bcheck.o
>  > 3) compiler specific standard header stddef.h, stdarg.h, ...
>  > 4) entire lib and include directories on win32
>  >
>  > 3)4) can be done by tcc_add_library_path() / 
> tcc_add_sysinclude_path() but not 1)2).
>
> "bcheck.o" is included in "libtcc1.a" in my (not recent Windows-)build. 
> Is this no longer the case?

Yes, but only on windows.

>  > So it seems that if you want to link your application with libtcc.a
> and run it on a system that does not have tcc installed you need
> tcc_set_lib_path() to tell libtcc.a where is libtcc1.a.  No?
>
> My test case actually was flawed before, but as far as I can tell,
>
>     tcc_set_lib_path(state, "<TCC-DIR>/win32");
>
> is equivalent to
>
>     tcc_add_sysinclude_path(state, "<TCC-DIR>/win32/include");
>     tcc_add_library_path(state, "<TCC-DIR>/win32/lib");

Only on windows.

> Do we really need a dedicated API for that, or is there something I'm 
> missing again?

Well, there was a thought to have one single API that accepts normal
command-line options and could replace more from the current API,
like:
  tcc_set_options("-B%s -I%s -l%s -D%s -g -Wall",
      my_tcc_path, my_inc_path, my_lib, my_define);

--- grischka