Will using cygwin help with back-linking?

[Frank Seesink]

Jay,

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 
download here:

	http://jabberd.jabberstudio.org/1.4/#download

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!
> 
> Jay West
> 
> 
> --
> [This E-mail scanned for viruses by Declude Virus]
> 
> 


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