This is the mail archive of the
mailing list for the Cygwin project.
Re: Will using cygwin help with back-linking?
- From: Frank Seesink <frank at mail dot wvnet dot edu>
- To: cygwin at cygwin dot com
- Date: Fri, 09 Apr 2004 17:29:29 -0400
- Subject: Re: Will using cygwin help with back-linking?
- References: <firstname.lastname@example.org>
You're not the first to run into this. From all I've gathered/read, the
short answer to your question whether Cygwin supports backlinking as you
expect in most *nix environments is _no_.
True, Windows does not support backlinking. True, you can play the
libtools game, build a stub library of your main .exe, then compile your
dynamic libs against that stub (it's a long, painful process), thus
being able to compile/link everything. [Note the build of your main
.exe gets rather ugly in this case, requiring quite a few steps.] But
in the end, what you're likely talking about--the pure simplicity of
being able to load a library using dlopen() and have functions within
that library access and potentially MODIFY global vars defined in the
main .exe--is simply NOT do-able in that simplistic sense.
For reference, check out the source code to JabberD 1.4.3, available for
Most importantly, look at the Makefiles (the one in ./jabberd/ builds
the main .exe and should give you the chills).
I struggled long and hard with this backlinking, and like certain
versions of BSD, backlinking is simply not supported. The actual
JabberD code builds, and from I can tell, simply 'accessing' global vars
in the main .exe is ok. However, ANY attempt to _modify_ those vars
will give you an exception error (basically 'access violation' as the
DLL tries to modify memory that is not its own) and make your app barf.
Not pretty. I know this because certain 'plugins' for JabberD are
written to make note of global vars in the main .exe and use them as
flags, changing the setting so other modules will know something is
enabled/disabled...kind of a semaphore setup. Only when I declared
local copies of those vars (thereby avoiding the DLL trying to modify
anything outside its own memory space) did things work. Luckily the
'semaphore' global vars in question weren't critical in nature, so the
inability to modify them didn't break the software.
In your case, depending on what you're trying to do, chances are you
best bet is re-arranging your code. Wish it weren't like that, but for
what it's worth, Cygwin/Windows isn't the only OS with this limitation
in backlinking. Can't remember which BSD it was (FreeBSD, NetBSD,
OpenBSD, etc.), but there's at least one that does not support
backlinking either. Gee, if we could only all just get along and have a
common API, huh? :-)
Jay West wrote:
I've googled and searched the cygwin FAQ, if my question is already answered
there perhaps someone can at least tell me what term to search for as
"back-linking" didn't seem to offer germane tips?
I'm new to cygwin. I have a Unix application I'd like to go through and make
sure it can also compile and run on a windows machine with cygwin. The Unix
application relies on "back-linking" with regards to dlopen'able modules.
Specifically, any dlopen'able module needs to have access to any variables
defined globally in the calling application. On Unix, when the module is
dlopened by the main program, it's references to global variables in the
main program are all resolved then.
From my googling and reading, I am told Windows does not support this
concept of "back-linking". So I was wondering if loading cygwin on the
machine will provide this feature, or am I left with totally restructuring
the application to stuff the global variable definitions into a library?
Any tips in the right direction are most appreciated!
[This E-mail scanned for viruses by Declude Virus]
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html