Domanda

I've downloaded the WSF-CPP 2.1.0 source, and set the vcvars to x86_amd64 (using VS 2008/9.0) but I'm running into problems:

  1. I had to disable the /WX compiler option in wsf_c/axis2c/build/win32/makefile to get anything to even try building, since the Axis2/C code is rife with warnings.
  2. Now I'm running into issues where multiple Axis2/C source files are trying to include nonexistent files, such as httpd.h, http_core.h, etc. (the specific offenders are in wsf_c/axis2c/src/core/transport/http/server/apache2).

Number 1 could just be a bad idea by whoever wrote the makefile and therefore something to ignore. But Number 2 seems to indicate a bigger problem than some missing headers, mainly because I'm able to compile the Axis2/c library as downloaded from the Apache web site without issue, but the code is identical (including the #includes of nonexistent headers). Does anyone know what could cause this difference?

Here, specifically, is how I'm trying to set the 64-bit environment variables up. All I did was replace this line in build.bat and wsf_c/build.bat:

@call vcvars32.bat /nologo

with

@call "C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\vcvarsall.bat" x86_amd64

Did I do this wrong? Did I mess up something else?

Also, this is my first question ever asked on StackOverflow. With respect to that, I'd appreciate any critiques about format, content, tone, appropriateness, etc.

È stato utile?

Soluzione

My first recommendation to any miserable individual trying to use the no-longer-supported, out-of-date WSO2 WSF/CPP/C or Axis2/C is to use a different library if at all possible. If you refuse to take this advice, continue reading.

Finally got it to build correctly through trial and error. Here's what it took:

  • As stated in my question I had to disable the /WX compiler option in wsf_c/axis2c/build/win32/makefile to get prevent the build from failing right away due to all the warnings in the Axis2/C code.
  • Also as stated in my question I had to change the line at the top of build.bat (either build.bat or wsf_c/build.bat works, since they run in the same console, and you only need to set the environment variables once per console session). I changed the line from

    @call vcvars32.bat /nologo
    

    to

    @call "C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\vcvarsall.bat" x86_amd64
    

    This sets up the compiler to build everything in a 64-bit configuration.

  • In wsf_c/build.bat I had to change the Axis2/C build command on (or near) line 11 from

    nmake dist AUTOCONF=..\..\..\configure.in
    

    to

    nmake install AUTOCONF=..\..\..\configure.in
    

    This magically fixed the missing header errors. I'd explain it if I had any idea why.

  • Then I had to add this line directly after that command:

    move ..\deploy ..\axis2c-bin-1.6.0-win32
    

    This was necessary to fix the rest of the build scripts, as they all reference the build directory as axis2c-bin-1.6.0-win32, even though Axis2/C actually puts everything in a folder called "deploy". If you're zealous for detail you could change every reference to that folder to have "win64" at the end, but I just wanted to get it working with the least possible effort.

But note that these are all steps above and beyond the initial install/build instructions that come in the WSO2 documentation. All of the steps indicated in WSO2's instructions are still also necessary (except anything exclusively for 32-bit, obviously).

And unfortunately this didn't solve my real problem, which was trying to load Rampart DLLs from Axis2/C. I was pursuing WSO2's implementation in hopes that they were building things in some better way, but alas, no luck. I'll post my Rampart problem in a separate, equally unlikely to be answered thread. I have yet to find a solution to that one anywhere on the web.

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top