logo
Apache Lounge
Webmasters

 

About Forum Index Downloads Search Register Log in RSS X


Keep Server Online

If you find the Apache Lounge, the downloads and overall help useful, please express your satisfaction with a donation.

or

Bitcoin

A donation makes a contribution towards the costs, the time and effort that's going in this site and building.

Thank You! Steffen

Your donations will help to keep this site alive and well, and continuing building binaries. Apache Lounge is not sponsored.
Post new topic   Forum Index -> Building & Member Downloads View previous topic :: View next topic
Reply to topic   Topic: XML::Parser compilation issues with Apache 2.4.58
Author
neoanantha



Joined: 09 Feb 2024
Posts: 5
Location: IN, BGL

PostPosted: Tue 20 Feb '24 20:28    Post subject: XML::Parser compilation issues with Apache 2.4.58 Reply with quote

XML::Parser-2.47.0 compilation issues with Apache 2.4.58 and Perl 5.38.0

We have a legacy MS Windows system which is all 32 bit and hence cannot use latest 64bit Mod_perl/Apache/Perl combination provide by Steve from below url

https://people.apache.org/~stevehay/mod_perl-2.0.12-strawberryperl-5.32.1.1-64bit.zip

Built Perl 5.38.0(32bit) from Source which went pretty fine and quick. Code Source

https://www.cpan.org/src/5.0/perl-5.38.0-RC1.tar.gz

Apache 2.4.58 (32bit) was built from source successfully from thread 8609 as below

https://www.apachelounge.com/viewtopic.php?t=8609&postdays=0&postorder=asc&start=0

With above 32-bit Apache/Perl combo env mod_perl-2.0.13(32bit) also got built successfully and installed into Apache24 install location

Modperl code from:
https://archive.apache.org/dist/perl/mod_perl-2.0.13.tar.gz

The issue is during installation of XML::Parser perl module through cpanm

This is the log from
Code:

C:\>cpanm XML::Parser --verbose
cpanm (App::cpanminus) 1.7044 on perl 5.038000 built for MSWin32-x86-multi-thread
Work directory is C:\Users\ADMINI~1/.cpanm/work/1708422680.4584
You have make "E:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.39.33519\bin\HostX86\x86\nmake.exe"
You have LWP 6.76
You have "C:\Program Files\Git\usr\bin\tar.exe", "C:\Program Files\Git\usr\bin\gzip.exe" and "C:\Program Files\Git\mingw64\bin\bzip2.exe"
You have "C:\Program Files\Git\usr\bin\unzip.exe"
Searching XML::Parser () on cpanmetadb ...
--> Working on XML::Parser
Fetching http://www.cpan.org/authors/id/T/TO/TODDR/XML-Parser-2.47.tar.gz
-> FAIL Download http://www.cpan.org/authors/id/T/TO/TODDR/XML-Parser-2.47.tar.gz failed. Retrying ...
-> OK
Unpacking XML-Parser-2.47.tar.gz
Entering XML-Parser-2.47
Checking configure dependencies from META.json
Checking if you have ExtUtils::MakeMaker 6.58 ... Yes (7.70)
Configuring XML-Parser-2.47
Running Makefile.PL

Expat must be installed prior to building XML::Parser and I can't find
it in the standard library directories. Install 'expat-devel' (or
'libexpat1-dev') package with your OS package manager. See 'README'.

Or you can download expat from:

http://sourceforge.net/projects/expat/

If expat is installed, but in a non-standard directory, then use the
following options to Makefile.PL:

    EXPATLIBPATH=...  To set the directory in which to find libexpat

    EXPATINCPATH=...  To set the directory in which to find expat.h

For example:

    perl Makefile.PL EXPATLIBPATH=/home/me/lib EXPATINCPATH=/home/me/include

Note that if you build against a shareable library in a non-standard location
you may (on some platforms) also have to set your LD_LIBRARY_PATH environment
variable at run time for perl to find the library.

-> N/A
-> FAIL Configure failed for XML-Parser-2.47. See C:\Users\ADMINI~1\.cpanm\work\1708422680.4584\build.log for details.


Expat-2.6.0 has already got installed as part of the Apache build as mentioned above into C:\Apache24

Solutions tried till now:

Extracted XML Parser code and directly ran

Code:
C:\Development\Apache24\src\XML-Parser-2.47>perl Makefile.PL EXPATHLIBPATH=C:\Apache24\lib EXPATINCPATH=C:\Apache24\bin


Again same message as above comes up

Several hack methods were tried from google in futile... have hit rock here

Please point me as to where am I making mistake

Any guidance towards a resolution to this problem would be much appreciated

btw there's no issue with cpanm installing other perl modules which is going absolutely fine. Have been able to install several other perl modules

Edit1:

Build machine details
- Windows 11 VM on an ESXi
- VS2022 Community Edition with C++ dev tools and VC++ chosen during install
Back to top
tangent
Moderator


Joined: 16 Aug 2020
Posts: 305
Location: UK

PostPosted: Tue 20 Feb '24 23:22    Post subject: Reply with quote

I can't reproduce your problem on my build platform, the one used to maintain thread 8609 (updated expat to 2.6.0).

The cpanm command successfully builds XML-Parser-2.47, e.g. here updating my Perl XML-Parser from 2.46 to 2.47

Code:
C:\temp>cpanm XML::Parser --verbose
cpanm (App::cpanminus) 1.7044 on perl 5.032001 built for MSWin32-x64-multi-thread
Work directory is C:\Users\User/.cpanm/work/1708460780.9352
You have make C:\Apps\perl\c\bin\gmake.exe
You have LWP 6.52
Falling back to Archive::Tar 2.38
You have C:\Bin\unzip.exe
Searching XML::Parser () on cpanmetadb ...
--> Working on XML::Parser
Fetching http://www.cpan.org/authors/id/T/TO/TODDR/XML-Parser-2.47.tar.gz ... OK
Unpacking XML-Parser-2.47.tar.gz
Entering XML-Parser-2.47
Checking configure dependencies from META.json
Checking if you have ExtUtils::MakeMaker 6.58 ... Yes (7.58)
Running Makefile.PL
Configuring XML-Parser-2.47 ... Checking if your kit is complete...
Looks good
Writing MYMETA.yml and MYMETA.json
Generating a gmake-style Makefile
Writing Makefile for XML::Parser
Writing MYMETA.yml and MYMETA.json
OK
Checking dependencies from MYMETA.json ...
Checking if you have LWP::UserAgent 0 ... Yes (6.52)
Checking if you have ExtUtils::MakeMaker 0 ... Yes (7.58)
Checking if you have warnings 0 ... Yes (1.47)
Checking if you have Test::More 0 ... Yes (1.302183)
Building and testing XML-Parser-2.47 ... cp Parser/Encodings/iso-8859-9.enc blib\lib\XML\Parser\Encodings\iso-8859-9.enc
...
<snip>
...
Installing C:\Apps\perl\perl\site\lib\XML\Parser\Style\Debug.pm
Installing C:\Apps\perl\perl\site\lib\XML\Parser\Style\Objects.pm
Installing C:\Apps\perl\perl\site\lib\XML\Parser\Style\Stream.pm
Installing C:\Apps\perl\perl\site\lib\XML\Parser\Style\Subs.pm
Installing C:\Apps\perl\perl\site\lib\XML\Parser\Style\Tree.pm
Appending installation info to C:\Apps\perl\perl\lib/perllocal.pod
OK
Successfully installed XML-Parser-2.47 (upgraded from 2.46)
Installing C:\Apps\perl\perl\site\lib\MSWin32-x64-multi-thread\.meta\XML-Parser-2.47\install.json
Installing C:\Apps\perl\perl\site\lib\MSWin32-x64-multi-thread\.meta\XML-Parser-2.47\MYMETA.json
1 distribution installed

Similarly, for me, the Makefile.PL and nmake ran against the module source without error, e.g.
Code:

C:\Development\Apache24\src\XML-Parser-2.47>perl Makefile.PL EXPATLIBPATH=C:\Apache24\lib EXPATINCPATH=C:\Apache24\include
Writing MYMETA.yml and MYMETA.json
Generating a gmake-style Makefile
Writing Makefile for XML::Parser
Writing MYMETA.yml and MYMETA.json

C:\Development\Apache24\src\XML-Parser-2.47>nmake

Microsoft (R) Program Maintenance Utility Version 14.38.33135.0
Copyright (C) Microsoft Corporation.  All rights reserved.

cp Parser.pm blib\lib\XML\Parser.pm
cp Parser/Encodings/ibm866.enc blib\lib\XML\Parser\Encodings\ibm866.enc
cp Parser/Encodings/iso-8859-5.enc blib\lib\XML\Parser\Encodings\iso-8859-5.enc
cp Parser/Encodings/big5.enc blib\lib\XML\Parser\Encodings\big5.enc
cp Parser/Encodings/iso-8859-2.enc blib\lib\XML\Parser\Encodings\iso-8859-2.enc
cp Parser/Encodings/iso-8859-7.enc blib\lib\XML\Parser\Encodings\iso-8859-7.enc
...
<snip>
...
"C:\Apps\perl\perl\bin\perl.exe" -MExtUtils::Command -e mv -- Expat.xsc Expat.c
gcc -c  -IC:\Apache24\include -DWIN32 -DWIN64 -D__USE_MINGW_ANSI_STDIO -DPERL_TEXTMODE_SCRIPTS -DPERL_IMPLICIT_CONTEXT -DPERL_IMPLICIT_SYS -DUSE_PERLIO -fwrapv -fno-strict-aliasing -mms-bitfields -s -O2   -DVERSION=\"2.47\" -DXS_VERSION=\"2.47\"  "-IC:\Apps\perl\perl\lib\CORE"   Expat.c
"C:\Apps\perl\perl\bin\perl.exe" -MExtUtils::Mksymlists \
     -e "Mksymlists('NAME'=>\"XML::Parser::Expat\", 'DLBASE' => 'Expat', 'DL_FUNCS' => {  }, 'FUNCLIST' => [], 'IMPORTS' => {  }, 'DL_VARS' => []);"
g++ Expat.def -o ..\blib\arch\auto\XML\Parser\Expat\Expat.xs.dll -mdll -s -L"C:\Apps\perl\perl\lib\CORE" -L"C:\Apps\perl\c\lib" Expat.o   "C:\Apps\perl\perl\lib\CORE\libperl532.a" "C:\Apps\perl\c\lib\libexpat.a" "C:\Apps\perl\c\x86_64-w64-mingw32\lib\libmoldname.a" "C:\Apps\perl\c\x86_64-w64-mingw32\lib\libkernel32.a" "C:\Apps\perl\c\x86_64-w64-mingw32\lib\libuser32.a" "C:\Apps\perl\c\x86_64-w64-mingw32\lib\libgdi32.a" "C:\Apps\perl\c\x86_64-w64-mingw32\lib\libwinspool.a" "C:\Apps\perl\c\x86_64-w64-mingw32\lib\libcomdlg32.a" "C:\Apps\perl\c\x86_64-w64-mingw32\lib\libadvapi32.a" "C:\Apps\perl\c\x86_64-w64-mingw32\lib\libshell32.a" "C:\Apps\perl\c\x86_64-w64-mingw32\lib\libole32.a" "C:\Apps\perl\c\x86_64-w64-mingw32\lib\liboleaut32.a" "C:\Apps\perl\c\x86_64-w64-mingw32\lib\libnetapi32.a" "C:\Apps\perl\c\x86_64-w64-mingw32\lib\libuuid.a" "C:\Apps\perl\c\x86_64-w64-mingw32\lib\libws2_32.a" "C:\Apps\perl\c\x86_64-w64-mingw32\lib\libmpr.a" "C:\Apps\perl\c\x86_64-w64-mingw32\lib\libwinmm.a" "C:\Apps\perl\c\x86_64-w64-mingw32\lib\libversion.a" "C:\Apps\perl\c\x86_64-w64-mingw32\lib\libodbc32.a" "C:\Apps\perl\c\x86_64-w64-mingw32\lib\libodbccp32.a" "C:\Apps\perl\c\x86_64-w64-mingw32\lib\libcomctl32.a" -Wl,--enable-auto-image-base
"C:\Apps\perl\perl\bin\perl.exe" -MExtUtils::Command -e chmod -- 755 ..\blib\arch\auto\XML\Parser\Expat\Expat.xs.dll

I note you have some typos in your expat variables (I used EXPATLIBPATH=C:\Apache24\lib EXPATINCPATH=C:\Apache24\include), but the only other difference I can see is you've built Perl from source, whereas I use the Stawberry Perl package (an older release and admittedly the 64 bit variant), but it does include GNU utilities. However, they shouldn't affect the CPAN side of things.
Back to top
neoanantha



Joined: 09 Feb 2024
Posts: 5
Location: IN, BGL

PostPosted: Wed 21 Feb '24 3:20    Post subject: Reply with quote

Building Perl from source is crucial for me as we need modperl... again 32 bit

Using Strawberry perl 5.32.1.1(32bit) worked fine for me as well in getting all Perl modules (including XML::Parser 2.47)

But modperl 2.0.12 as well as 2.0.13 source would start complaining with Apache 2.4.58(32bit) and strawberry Perl 5.32.1.1(32bit) throwing up several linker errors

cpanm would always fail for modperl

Only difference is my environment is always vanilla... no earlier versions of any perl modules or any other component source would not exist

This issue that I'm hitting is consistently reproducible with the said vanilla environment and components from 8609 thread when built from scratch

Went back to strawberry perl

https://github.com/StrawberryPerl/Perl-Dist-Strawberry/releases/tag/SP_5382_32bit

Started hitting modperl 2.0.13 compilation issues here as well Sad


Edit1:

That was indeed typo in EXPATINCPATH... my bad in the first post

In my actual execution it was indeed EXPATINCPATH=C:\Apache24\include but was still hitting the issue as mentioned
Back to top
neoanantha



Joined: 09 Feb 2024
Posts: 5
Location: IN, BGL

PostPosted: Wed 21 Feb '24 3:27    Post subject: Reply with quote

Do you see any issues with my build environment

It's Windows 11 22H2 with latest updates

Should I setup entire thing on Windows 10?

Everything else is working fine though

Would you please let know the build OS being used for 8609
Back to top
tangent
Moderator


Joined: 16 Aug 2020
Posts: 305
Location: UK

PostPosted: Wed 21 Feb '24 14:47    Post subject: Reply with quote

The build environment for thread 8609 is also Windows 11 22H2 with latest updates, so I don't believe regressing to Windows 10 will make any difference.

Since your problem appears to be with the later mod_perl build process, I'd start looking into its Makefile.PL, etc. to see what's changed from previous releases.

I see the script wants apxs, and offers to install a development port. If your build errors relate to missing header files, etc., this is where I'd concentrate my efforts.
Back to top
neoanantha



Joined: 09 Feb 2024
Posts: 5
Location: IN, BGL

PostPosted: Wed 21 Feb '24 19:37    Post subject: Reply with quote

it's building fine with strawberry perl 5.32.1.1(32bit) and also with 5.38.2(32bit)

Made a small hack wherein set the env vars of perl installdir to point to strawberry perl 5.38.2 and got the cpanm XML::Parser built

After successful build it's creating

Code:
C:\perl\site\lib\auto\XML\Parser\Expat\Expat.xs.dll


But my existing legacy windows/perl setup which is more than a decade old is using Activestate Perl v5.16.3 (32bit) is having different dll name as below

Code:
C:\perl\site\lib\auto\XML\Parser\Expat\Expat.dll


And with Apache httpd 2.4.58(32bit), when an attempt is made to start is also asking for Expat.dll

Does ActiveState build their perl in some propriety way that is different from strawberry perl or perl from source is built?

To further investigate on this trail.. signed up to activestate and downloaded through their propriety process ActiveState Perl version 5.36.3 and to my surprise they have Expat.dll rather than Expat.xs.dll in the same location as mentioned above

As per your build could you please let know as to which expat dll (with or without xs) got created after
cpanm XML::Parser

sadly again I cannot use activestate perl 5.36.3 built XML::Parser module since it has generated 64bit Expat.dll
Back to top
tangent
Moderator


Joined: 16 Aug 2020
Posts: 305
Location: UK

PostPosted: Wed 21 Feb '24 22:50    Post subject: Reply with quote

Scanning my build system, the following expat dll file got created via the cpanm command.

Code:
C:\>dir \Apps\perl\perl\site\lib\auto\XML\Parser\Expat
 Volume in drive C is Windows
 Volume Serial Number is ACBD-83FF

 Directory of C:\Apps\perl\perl\site\lib\auto\XML\Parser\Expat

20/02/2024  20:26    <DIR>          .
20/02/2024  20:26    <DIR>          ..
20/02/2024  20:26            71,680 Expat.xs.dll
               1 File(s)         71,680 bytes
               2 Dir(s)  70,682,374,144 bytes free

In my experience, ActiveState Perl has always been somewhat 'proprietary' compared to Strawberry Perl.

So if the issue is Expat.xs.dll vs Expat.dll, could you try creating a symlink from one variant to the other? Sorry, not sure what else to advise.
Back to top
neoanantha



Joined: 09 Feb 2024
Posts: 5
Location: IN, BGL

PostPosted: Sun 03 Mar '24 21:32    Post subject: Reply with quote

In ActivePerl (5.26 as well as prior upto 5.16 have checked) both expat.dll and also expatxs.dll both exists

There's few KBs worth of size difference as well
Back to top


Reply to topic   Topic: XML::Parser compilation issues with Apache 2.4.58 View previous topic :: View next topic
Post new topic   Forum Index -> Building & Member Downloads