Re: External functions in a (to a) DLL?

["Yaakov (Cygwin Ports)" <yselkowitz at users dot sourceforge dot net>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Michael Rogers wrote:
| I had been attempting to port a graphing/plotting library developed on
*nix/xwindows and using tcl/dk. It came in a standard tarball
distribution with config and automake scripts set up for the expected
*nix platorms. After wrestling with that for a while I finally got the
library source files to build with all the right include directories and
libraries.
| Then it had only four remaining functions for which it has undefined
references. One of them looks ok in the source code and will just take
some digging to figure out why the linker is complaining.  The other
three are external functions that are declared in a header and invoked
at a few places in some of the library functions and that are expected
to be defined by the user in every application that calls this library.
 The original *nix version of this library was static, so this is
probably a trivial thing, in that case. But it won't link a DLL at this
point with undefined references. I'm guessing there would be a problem
even making a static library with the linker as well.  The original
distribution use "ar" and then "randlib" to create the library.  That
seems to be a pretty safe way to build a static library.
| This is more of C programming question than anything else, but, can
you build a DLL that uses these sorts of absrtact external functions? I
would suspect not. There a fortran interface version has the missing C
function but it just redirects it a similarly named function declared
"extern". In the sample fortran program this corresponding to a
subroutine.  Unfortunately, when I try to link the fortran interface
version it doesn't like the undefined reference to the new external
replacement. But just in case, I tried explicitly casting them as
"extern void" in the C files that had the problem originally.  As long
as I was consistent with the headers, it compiled but it didn't resolve
the linking issue.
| So, is this a fools errand, or is there a way to handle these kinds of
external function calls within a DLL?  Would it be better to just link
it as a static library? I was trying to build it as a DLL because it
used the X11 libraries and I thought it would either be necessary or
more consistent with cygwin to make it into a DLL, but I'm beginning to
think that might not be possible (unless I rewrite the library so as to
circumvent need for the external function calls in the library).
| On the other hand, I also think people must do this sort of thing
somehow, given all the ports to cygwin out there and the fact that this
is probably a pretty common programming practice.  Anybody know whether
or not, and if so how, you can get a DLL to link with externally defined
functions in the code?

If I follow you, you want to create a library that has undefined symbols
which will be provided by a program linked against said library.

The answer to your question depends on if the library is meant to be
linked against only one particular program (probably coming together
with the library), against any of a group of programs, and/or against
another library.

If the library needs to be linked against another library or plugin,
you'll need to force this library to be shared, which may be possible
but will take some work.

If the library is meant to be linked against one particular program, a
static library will be much easier, but a shared one is also technically
possible.

If the library is meant to be linked against any number of programs,
then your only choice is to make it static.


Yaakov
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEAREIAAYFAkiakyMACgkQpiWmPGlmQSOn2wCgn3ZxuJHvQ6Oma7TCxJiDQmbp
0hsAoI0TVeV+ezzWC0TtAyHZhfKpQpFc
=+t2+
-----END PGP SIGNATURE-----

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://x.cygwin.com/docs/
FAQ:                   http://x.cygwin.com/docs/faq/