Can you make a DLL from a library that requires caller-defined functions?

[Michael Rogers]

I previously used the subject line "External functions in a (to a) DLL" but I think this is more accurate.
Yaakov wrote:
-----------------------------------------------------------------------------------------------------
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.
----------------------------------------------------------------------------------------------------
Yes, precisely.  It has symbols for routines that are declared in a header file and called in some of the library routines.  But they are actually required to be defined in the calling program. Thinking back to libraries I've linked to in the past, I don't think this is an entirely uncommon practice, at least with not static libraries.
Yaakov continues..
-------------------------------------------------------------------------------------------------
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.
-------------------------------------------------------------------------------------------------
It's fine with me to make it static but it has dependencies on the X11 and Xpm libraries, which are DLLs.  So would it be ok to make it at static library?
The original library was static and was intended to be linkable against arbitrary calling programs, as long as they define the three required functions within them.  I want this library only because it is used in one specific physics program - that's my real goal.  So I don't absolutely need it to be linked against any other programs (but the test programs  would be nice).  
It would require a more serious rewrite to eliminate these routines in the library because one of the user-defined functions is basically the actual physics loop of the calling program.  This is activated by a library function that effectively starts the real computing by calling the physics loop via this user-defined routine. That may sound convoluted but it looks quite logical when you actually see it coded in the calling routine. It just makes for a really short "main" loop and all the real action goes into this new function.  Also, the other two routines are user-defined dump and quit actions.  For the test programs these are trivial - just printf statements - but I'm sure with the real physics program I'm trying to get compiled they'll involve file IO routines, at minimum. And they are called (wrapped) within the library's dump and quit routines.  So it probably wouldn't be trivial to get where I want by just eliminating
 these functions from the library.
So should I make it static and will this work with cygwin-x and DLLs it needs to link to?  And if it's both necessary and possible to make it a DLL, then I presume it will take some extra work, perhaps a fair amount, so could you direct me to an explaination or a tutorial page or something that spells out the steps involved. I don't mean to fixate on DLLs but if this is doable, this would be a a really worthwile little trick to know how to do.
It's also possible that I just can't make the library this way in cygwin so then I'dl have to rewrite both the graphics library and the calling program to disentangle them.  I guess I'll do that if I really have to.  It would really just require making the main loop encompass everything now in the user-defined loop routine and probably handling the dump and quit routines entirely within the calling program, and that might not be as bad as I had been thinking.  It just seems inelegant.




--
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/