This is the mail archive of the cygwin mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Will using cygwin help with back-linking?


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:

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:
Problem reports:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]