A brief update. Partial replies to Gerritt. Self-corrections.
Soren A [EMAIL PROTECTED] wrote
in [EMAIL PROTECTED]:">news:[EMAIL PROTECTED]:
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/
