[ expat-Bugs-432456 ] DLL name 'expat.dll' causes problems
noreply@sourceforge.net
noreply@sourceforge.net
Thu May 30 21:05:03 2002
Bugs item #432456, was opened at 2001-06-12 12:25
You can respond by visiting:
http://sourceforge.net/tracker/?func=detail&atid=110127&aid=432456&group_id=10127
Category: Build control
Group: Platform Specific
>Status: Closed
Resolution: Fixed
Priority: 6
Submitted By: Kevin Gilpin (kgilpin)
Assigned to: Karl Waclawek (kwaclaw)
Summary: DLL name 'expat.dll' causes problems
Initial Comment:
On Win32, when attempting to build the XML::Parser
Perl module with expat, the name 'expat.dll' is used
by both projects. This causes problems when running
XML::Parser, because only one of the 2 dlls can be
loaded.
By changing the output target of expat
to 'libexpat.dll' (and generating and linking against
the corresponding libexpat.lib) I was able to get
XML::Parser successfully built and running on Win NT.
----------------------------------------------------------------------
>Comment By: Karl Waclawek (kwaclaw)
Date: 2002-05-31 00:04
Message:
Logged In: YES
user_id=290026
Ran your changed MSVC projects.
Seems to work for me. All you really needed
to do is add the XML_UNICODE_WCHAR_T
preprocessor definition (for the libexpatw project),
and change the name in the link options.
Karl
----------------------------------------------------------------------
Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-05-30 23:15
Message:
Logged In: YES
user_id=3066
Added new project, "expatw", to the Expat MSVC workspace. This
*should* be the right change to build a wchar_t version of Expat using the
DLL name libexpatw.dll (both Debug and Release
versions).
Karl, I don't have any code to use the new versions of
the library. Could you test and close this report if we're really done?
Thanks!
----------------------------------------------------------------------
Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-05-30 22:36
Message:
Logged In: YES
user_id=3066
Changed the name of the Expat DLLs on Windows from "expat.dll" to
"libexpat.dll", solving the original bug. See lib/expat.dsp 1.8 and
examples/elements.dsp 1.3.
Creating the "w" version of the
DLL is a separate change to the project files; I'll try to do this next. The
report is now marked "Fixed" since the bug is fixed; what remains is a
new feature, and therefore a slightly lower priority.
I'm not sure
why the name of the DLL does not appear in the other .dsp files -- if anyone
can enlighten me, I'd certainly appreciate it!
----------------------------------------------------------------------
Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-05-30 15:54
Message:
Logged In: YES
user_id=3066
Bumped priority.
----------------------------------------------------------------------
Comment By: Gerrit Haase (siebenschlaefer)
Date: 2002-05-25 06:01
Message:
Logged In: YES
user_id=76037
On Cygwin we use libtoll which manages the naming.
If you would use automake too... (yes I know...).
Libtool names the lib cygexpat-0.dll
since there is no versioning which is compatible with libtool.
If the API changes it would be named cygexpat-1.dll so both
versions may coexist.
It would be very easy to transfer this to the Windows version.
Just name it winexpat-0.dll and so on, so every conflict can
be avoided, e.g. using expat on windows in three versions
(cygwin, native windows, perl).
Just my 2c.
Gerrit
----------------------------------------------------------------------
Comment By: Karl Waclawek (kwaclaw)
Date: 2002-05-25 00:06
Message:
Logged In: YES
user_id=290026
On Linux I was already using libexpat.so and libexpatw.so
(w stands for "wide").
So, why not use libexpat.dll and libexpatw.dll?
Just to create confusion,
Karl
----------------------------------------------------------------------
Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-05-23 15:14
Message:
Logged In: YES
user_id=3066
While we may have some "right" to the name "expat" for the
DLL, older versions of expat used "xmlparse" and "xmltok",
and the Perl module started using "expat" (perhaps for some
technical reason, since the Perl module is XML::Parser::Expat).
I'll vote that we should call our DLL "libexpatutf8" when
compiled for UTF-8 output, and "libexpatutf16" when compiled
for UTF-16 output.
Yeah, that's new for everyone, and annoying as hell, but
beats making Expat support both output encodings in one
compiled version. (Well, except when you really want both.)
----------------------------------------------------------------------
Comment By: Nobody/Anonymous (nobody)
Date: 2002-05-21 20:39
Message:
Logged In: NO
It took a coule of hours to get things working on my machine
(Win2k sp2), so I thought I'd post what I did so others won't
waste time. I'm not sure if what I did was the correct method,
but it worked for me.
1) Download and extract the XML::Parser ZIP from CPAN.
3) Replace all occurances of "expat" with "libexpat" in all
files.
3) Rename the Expat directory to libexpat.
4) Rename the expat.pm and expat.xs files accordingly.
5) Open libexpat.xs and change the #include<libexpat.h>
back to #include<expat.h>
6) Build the make files (perl makefile.pl)
7) Open the libexpat makefile and change the
PERLARCHIVE line to read (note, I put expat.h, dll, and lib in
my perl\lib\CORE directory):
PERL_ARCHIVE = $(PERL_INC)\perl56.lib $(PERL_INC)
\expat.lib"
8) Run namke
9) Copy the PERL\lib\CORE\expat.dll to
blib\arch\xml\parser\libexpat and run 'nmake test'.
----------------------------------------------------------------------
Comment By: Greg Stein (gstein)
Date: 2002-05-17 20:55
Message:
Logged In: YES
user_id=6501
Calling the library expat2.dll would be fine with me.
libexpat.dll might also be fine.
But also note: *we* are Expat, not the Perl extension. We
have more "right" to expat.dll if that is what we choose to do.
----------------------------------------------------------------------
Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2001-10-01 18:08
Message:
Logged In: YES
user_id=3066
So this appearantly never worked with Expat 1.95+. Sigh.
We could go back to xmlparse.dll I suppose, but I don't
really like that. I don't know that we've retained enough
compatibility with that. Perhaps "expat2" would be good
enough, since the real target right now is a stable Expat 2.0.
I'll think about this a little more, but I'd like to have it
solved in Expat 1.95.3.
Assigning to me since Clark has been abducted by aliens.
----------------------------------------------------------------------
Comment By: Kevin Gilpin (kgilpin)
Date: 2001-10-01 17:51
Message:
Logged In: YES
user_id=44882
The problem is that the Perl extension consists of 2 dlls:
1) the expat DLL, which does not contain any perl references
2) the perl -> expat DLL, which references both the Perl
APIs and the Expat APIs
Both of these DLLs are called 'expat.dll', which is a
problem b/c Windows will cannot tell the difference between
them when the Perl program is run
----------------------------------------------------------------------
Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2001-10-01 16:26
Message:
Logged In: YES
user_id=3066
Thinking about this again, I realize I don't know enough
about the Perl extension machinery and mod_perl to be sure
of this. Is mod_perl providing an expat.dll which is
something different, or is it a different version of that
mod_perl uses?
We need a mod_perl/XML::Parser expert to answer reports like
this one! Leaving this one assigned to Clark until we have
such a person with available time.
----------------------------------------------------------------------
Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2001-07-25 12:39
Message:
Logged In: YES
user_id=3066
This relates to having multiple versions of the library being made available in the same process. Assigned to Clark since he might have more of the context information related to XML::Parser.
----------------------------------------------------------------------
You can respond by visiting:
http://sourceforge.net/tracker/?func=detail&atid=110127&aid=432456&group_id=10127