Download and build the 3rd party dependencies
./build-depkgs-mingw32
+Note, that during the build process you will see a moderate amount of
+output. If something fails, it is probably because you don't have one
+of the build dependencies (hopefully all mentioned above) loaded on your
+system. To find out what is going wrong, do the following:
+
+ cd .../depkgs-mingw32/src/<package-name>
+
+where <package-name> is where the package is unpacked and built. Normally
+it is relatively obvious when looking at the src directory.
+
+In that directory, you should find a make.log, which has the full details
+of the compiles, links, and installs done for that package.
+
+Note, if you are building on a 64 bit machine, please know that
+the build for the depkgs-mingw32/scons puts the python scons libraries
+in depkgs-mingw32/scons/lib64 but when running scons it looks for the
+libs in depkgs-mingw32/scons/lib. So adding symlink from
+depkgs-mingw32/scons/lib64 to depkgs-mingw32/scons/lib will fix the
+problem.
+
You need the header files from the Microsoft VSS SDK. Unfortunately the SDK
can only be downloaded and installed on a Windows system. You can find it on
Microsoft's web-site at:
"download volume shadow copy service sdk"
+we are currently using version 7.2 released 8/3/2005.
+
Normally the files will be installed in:
c:\Program Files\Microsoft\VSSSDK72
You only need to copy everything under the c:\Program Files\Microsoft\VSSSDK72\inc
-directory into .../depkgs-mingw32/vss/inc.
+directory into .../depkgs-mingw32/vss/inc. In doing so, please ensure that
+the case in maintained on the directory and filenames -- some contain uppercase
+characters !!!
The above only needs to be done once unless we change the cross-tools
or the dependencies versions. In general, you can run the script multiple
must be declared in a header file and MUST NOT be declared in a
source file referencing the variable.
+Exporting functions is now more or less automated. If you find that
+a function name has been added, changed, or an argument modified,
+simply do the following:
+
+ cd .../bacula/src/win32/dll
+ make (to build the .o files, note the link will fail)
+ ./make_def >bacula.def
+
+This should rebuild the bacula.def file.
+
+===== manual changing of bacula.def no longer necessary =====
+If you want to do it manually, please see below:
Exporting a function requires a bit more work. You must determine the
C++ mangled name of the new function.
in the file
.../bacula/src/win32/dll/bacula.def
+=== end manual changing of bacula.def ==========
If you add a new file, you will need to specify its name in
New data variables are exported by placing their name in the file
.../bacula/src/win32/cats/bacula_cats.def.
+As with the bacula.def file above, this is now more or less automated.
+When the link dies, simply do the following:
+
+ cd .../bacula/src/win32
+ make (to build the .o files, note the link will fail)
+ cd cats
+ ./make_def >bacula_cats.def
+
+This should rebuild the bacula_cats.def file. Note, if you have
+changed any data entry points, you will need to modify the make_def
+script -- it should be rather obvious.
+
+
+===== manual changing of bacula_cats.def no longer necessary =====
Exporting a function requires a bit more work. You must determine the
C++ mangled name of the new function.
which contains the new function. Replace <symbol> with the name of
the new function. Remove the leading underscore and place the result
in the .../bacula/src/win32/cats/bacula_cats.def file.
+=== end manual changing of bacula_cats.def ==========
Structure of the MinGW32 build environment