Hi Andy,
I have a Windows application that loads libtcc1-32.a or libtcc1-64.a
dynamically, all I did was to call both with of these:
tcc_set_lib_path
tcc_add_library_path
before calling tcc_compile_string (not sure if both of these are needed but
that’s what I did originally).
The path that I passed to those functions has a sub-folder called lib that
contains libtcc1-32.a and libtcc1-64.a,
Not sure it’s that simple in tcc4tccl but hope that helps.
Best regards,
Louis
From: Tinycc-devel <[email protected]> On
Behalf Of Andy Goth
Sent: Monday, March 11, 2019 9:28 PM
To: [email protected]
Subject: Re: [Tinycc-devel] Undefined symbol '__ashldi3'
My application is a Tcl interpreter, so it doesn't directly link with libtcc1.a
and rather tries to dynamically load it. This is working fine with 32-bit Linux
but not Windows.
In trying to force linking with libtcc1.a, I hit more problems. The main issue
is that without "-Wl,-whole-archive", the linker sees no reason to include any
part of libtcc1.a, since no part of the application uses it. Then when I do use
"-Wl,-whole-archive", I get other link errors due to other object files in
libtcc1.a that I don't care about, stuff about WinMain or whatever. Sorry, I
didn't bother to take detailed notes on that, since I moved on to directly
trying to pull in libtcc1.o and alloca86.o since that's all I think I need. But
while I did get them to link by hand, I couldn't figure out how to mechanize
the required link command within the framework of the Tcl application build
system, so I couldn't invoke the rest of the build process needed to give the
interpreter its virtual filesystem.
So I'm stepping back from that to ask how it's supposed to work for my
application to link to libtcc1.a rather than rely on tcc to dynamically load
libtcc1.a, which is what it's doing nicely on Linux already.
Granted, this libtcc1.a dynamic loading might be bolted onto tcc by the patches
that come with tcc4tcl, so if anything I'm saying sounds alien to the design of
tcc, let me know so I can bug the tcc4tcl author instead.
I tried hard to use gdb to debug dynamic loading, but it's proving to be a
nightmare in Windows. gdb is not showing me my arguments, it's claiming all
functions are defined in some unrelated C++ header file, and I had to find and
build debugbreak.c just to be able to Ctrl+C my process and get back to the gdb
prompt. And stdout isn't working for me either. So I'm really not sure how to
debug. Nevertheless, I do see that pe_add_runtime() is being called, which in
turn tries and fails to load libtcc1.a using tcc_add_dll(). I wish I could
inspect the arguments being passed to tcc_add_file_internal(), but gdb is not
cooperating, despite me compiling everything with -ggdb3 and forgoing the strip
stage of the Tcl build process.
On Fri, Mar 8, 2019, 08:04 Michael Matz
<[email protected]<mailto:[email protected]>> wrote:
Hi,
On Fri, 8 Mar 2019, Andy Goth wrote:
> On Fri, Mar 8, 2019, 00:46 Andy Goth
> <[email protected]<mailto:[email protected]>> wrote:
>
> > With tcc4tcl 0.30 (tcc 0.9.26) compiled with MXE GCC 5.4.0, I get the
> > following error:
> >
>
> I left out a critical detail. This is 32-bit Windows MXE GCC. I haven't
> tried 64-bit Windows yet, but it works fine in both 32- and 64-bit Linux.
Yes, only 32bit code emits calls to this function, on both Windows and
Linux. The function is defined in either libgcc.a or libtcc1.a which
TCC automatically should link against (either of them). Somehow this is
not happening, I can't say why, you'll have to figure it out.
Alternatively, if there are reasons why you don't link against libtcc1.a
or libgcc.a you will have to provide an implementation of this function
yourself, you could look into lib/libtcc1.c source for that.
There are other helper functions that TCC might also generate calls for
in the i386 backend:
__divdi3 long ret,x,y; ret = x / y;
__udivdi3 ulong ret,x,y; ret = x / y;
__moddi3 long ret,x,y; ret = x % y;
__umoddi3 ulong ret,x,y; ret = x % y;
__ashrdi3 long ret,x,y; ret = x >> y;
__lshrdi3 ulong ret,x,y; ret = x >> y;
__floatundisf ulong -> float
__floatundidf ulong -> double
__floatundixf ulong -> long double
__fixunssfdi float -> ulong
__fixunsdfdi double -> ulong
__fixunsxfdi long double -> ulong
__fixsfdi float -> long
__fixdfdi double -> long
__fixxfdi long double -> long
So it's probably easier to just figure out why libtcc1.a isn't linked
automatically with your program.
Ciao,
Michael.
_______________________________________________
Tinycc-devel mailing list
[email protected]<mailto:[email protected]>
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
_______________________________________________
Tinycc-devel mailing list
[email protected]
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
