Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com To: cygwin AT cygwin DOT com X-Injected-Via-Gmane: http://gmane.org/ Path: not-for-mail From: Soren A Subject: Re: The Black Art of DLL Creation (revisited) Date: Mon, 25 Nov 2002 23:10:22 +0000 (UTC) Organization: Sporadically, Occasionally Lines: 84 Message-ID: References: NNTP-Posting-Host: 107.syracuse-03-04rs.ny.dial-access.att.net X-Trace: main.gmane.org 1038265822 4658 12.89.1.107 (25 Nov 2002 23:10:22 GMT) X-Complaints-To: usenet AT main DOT gmane DOT org NNTP-Posting-Date: Mon, 25 Nov 2002 23:10:22 +0000 (UTC) User-Agent: Xnews/5.04.25 X-Archive: encrypt A brief update. Partial replies to Gerritt. Self-corrections. Soren A wrote in news:Xns92CE8DFF2E1BCsoren1Gmane AT 80 DOT 91 DOT 224 DOT 249: > The scenario is that I am trying to re-create the process of building > bleadperl [...] but one thing that > you can get from using dlltool, that you don't (I think?) get from > using 'gcc -shared' is a .DEF file that is basically correct. If you > ask 'gcc -shared' for a .DEF output using the appropriate switches, > you get included stuff like a .bss[data?] that isn't supposed to be > exported. OK, I see that this had been fixed in the interim. No longer any need at all to use dlltool explicitly unless we need a .exp file (and why would we? I do not in fact know). > I would like (for reasons that may not seem important to others) to > have a valid (by which I mean 'containing all symbols [functions and > global data] that need to be exported [visible to external exes] by > the DLL, and none that do not') .DEF file to work with. (OK, one > reason is that I am interested in the internals of Perl, and examining > the contents of the .DEF file gives a glimpse into those internals). > 2. Only a handful of symbols were listed under EXPORTS. These > symbols were all prefixed "XS_[foo]" and it is possible, based on my > examination of the source, that these functions were declared in > some way that doesn't involve "__declspec(dllexport)". The > dozens of other symbols that one expects and needs to see weren't > exported. [...] > I made sure that the Perl macros "EXT" and "cEXT" (constant) etc. were > being properly substituted with "__declspec(dllexport)". The header in > the cygwin/ subdir of the Perl src tree causes it NOT to be set, -- > Gerrit and others who are knowledgeable about CygwinPerl may note this > -- but I found a way to override that. Actually I didn't. I hoped that I had and believed that I had, but it was NOT working. I had to learn more about cpp through trial-and-error experimentation and using some tricks, in order to detect this and control it. > Backing up: in theory TTBOMU, if I've thus marked a symbol for export > this way, the Cygwin port of GNU ld(1) *should* export it > unconditionally. Furthermore, TTBOMU, this SHOULD only be necessary > for global variables (data) in the first place -- all *functions* > should be exported anyway(?). In cases where the src package has no > provisions for this, we've used the "--export-all" switch (for either > dlltool OR 'gcc -shared') to cause eveything but the special Cygwin > excluded symbols relating to entry points, etc. to be marked for > export in the final DLL. This is what the CygwinPerl build setup does > at present, and I don't understand why. The mechanism for marking > symbols with "__declspec(dll[ex|in]port" is already part of Perl src. > Why can't we use it? Clearly *somebody* does or did -- probably MSVC > does. I forced the symbols to be marked for export. So, anyway, I was wrong about this behavior on the part of dlltool and ld. I have built the DLL and linked in the Perl executable with some manipulation of which symbols get exported from the DLL, by using `nm' and friends to examine the exports closely. The current setup I have is that I can either choose to generate a .DEF file, or not, and link using the file, or not. There is some difference between what gets exported between those two cases. I'd be happy to discuss that if anyone who is knowledgeable, is interested. I can also control (with approaches that i haven't written about in this thread) the names of the generated libraries (all flavors: DLL [which is really an executable instea dof a classic library], interface lib, and static archive lib. I'v got a massively strange and interesting (to me alone, probably) experiment going here. Best, Soren A -- What do Internet Mailing Lists and crowded neighborhoods have in common? Both will either drive you out or teach you how to ignore barking dogs. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/