public inbox for gcc-help@gcc.gnu.org
 help / color / mirror / Atom feed
From: "René B. Nielsen" <rbn@vitesse.com>
To: <gcc-help@gcc.gnu.org>
Subject: Forcing linking despite of undefined references
Date: Wed, 14 Apr 2004 15:29:00 -0000	[thread overview]
Message-ID: <FD6CA6C74666E546981AEBE7F147C512886AEA@mx-dk1.dk.vitesse.com> (raw)

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
 

             reply	other threads:[~2004-04-14 15:29 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-04-14 15:29 René B. Nielsen [this message]
2004-04-15 13:58 ` llewelly

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=FD6CA6C74666E546981AEBE7F147C512886AEA@mx-dk1.dk.vitesse.com \
    --to=rbn@vitesse.com \
    --cc=gcc-help@gcc.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).