Mail Archives: cygwin/2004/04/09/17:30:07
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/
- Raw text -