Forcing linking despite of undefined references

Forcing linking despite of undefined references

[René B. Nielsen]

Hi,
 
TCL shells support loading of shared libraries on the fly with the "load" TCL command. The loaded library contains functions, that after the load are made available as TCL commands. Thus, there is an interaction between the shell and the shared library: The shell calls functions in the shared library, and the shared library calls functions already present in the shell to transfer results back to the shell.
 
Now, in order to build the shared library/shared object/DLL, I do the following (under Cygwin):
 
gcc -shared test.c -o libtest.dll -ltcl
 
The resulting DLL works fine as long as the tclsh is the one that comes with Cygwin, because I link with the Cygwin-enabled TCL library (-ltcl).
 
When I move to another TCL shell that has the exact same interface, it doesn't work, probably because loading libtest.dll causes a subsequent load of the Cygwin tcl.dll, which clashes with the functions inherently loaded by the TCL shell.
 
Therefore I thought of not linking with a specific TCL dll, but leave the -ltcl out, forcing the load of libtest.dll to use the TCL functions already present in whatever shell I use (provided the names of the functions and the interface is the same, of course). But this results in undefined references to "_Tcl_GetObjResult" and four other functions used in test.c. 
 
And now for the actual question: Is it possible to force gcc (or ld) to create the DLL even when there are undefined references? Or even better: Is it possible to specify the names of those functions that the linker shouldn't try to resolve?
 
Any help is highly appreciated.
 
/René Bøje Nielsen
 

Re: Forcing linking despite of undefined references

[llewelly]

René B. Nielsen <rbn@vitesse.com> writes:

F> Hi,
>  
> TCL shells support loading of shared libraries on the fly with the "load" TCL command. The loaded library contains functions, that after the load are made available as TCL commands. Thus, there is an interaction between the shell and the shared library: The shell calls functions in the shared library, and the shared library calls functions already present in the shell to transfer results back to the shell.
>  
> Now, in order to build the shared library/shared object/DLL, I do the following (under Cygwin):
>  
> gcc -shared test.c -o libtest.dll -ltcl
>  
> The resulting DLL works fine as long as the tclsh is the one that comes with Cygwin, because I link with the Cygwin-enabled TCL library (-ltcl).
>  
> When I move to another TCL shell that has the exact same interface, it doesn't work, probably because loading libtest.dll causes a subsequent load of the Cygwin tcl.dll, which clashes with the functions inherently loaded by the TCL shell.
>  
> Therefore I thought of not linking with a specific TCL dll, but leave the -ltcl out, forcing the load of libtest.dll to use the TCL functions already present in whatever shell I use (provided the names of the functions and the interface is the same, of course). But this results in undefined references to "_Tcl_GetObjResult" and four other functions used in test.c. 
>  
> And now for the actual question: Is it possible to force gcc (or ld)
> to create the DLL even when there are undefined references? Or even
> better: Is it possible to specify the names of those functions that
> the linker shouldn't try to resolve? 

This is really a binutils question. Try emailing binutils at gnu.org .