On 1/12/2016 8:41 AM, LM wrote:
.... So, I looked up how to build on Windows with
MinGW and tried again using make -f win/Makefile.mingw. Had to move
the location of LIB in:
$(TCC) -o $@ $(OBJ) $(EXTRAOBJ) $(LIB) $(OBJDIR)/fossil.o
to
$(TCC) -o $@ $(OBJ) $(EXTRAOBJ) $(OBJDIR)/fossil.o $(LIB)
since libraries need to be after the object files that reference them.
Did you actually try compiling with Makefile.mingw as is?
While it is in general true that the libraries should be after all
objects, the link line as it is does link with no undefined externals on
my PC, using MinGW and GCC 7.7.2.
My standard build recipe is at the MSYS bash prompt:
$ fossil clean
$ make -f win/Makefile.mingw FOSSIL_ENABLE_JSON=1
At least from the tip of today's trunk, that defaulted to the internal
zlib in compat/zlib. I've been running builds from that recipe on my
Windows PCs ranging from XP to 8.1 without issues.
The FOSSIL_ENABLE_JSON=1 is the equivalent of ./configure --with-json,
and is only needed because I want the JSON support, not because it was
required to build on Windows.
....
I'm not sure if my build of Fossil is using relevant system libraries.
Looks like the configure system checks for iconv and dlopen support
(libdl on Windows), but I don't see references to libiconv or libdl in
the Makefile.mingw file and I have them installed and available on my
system.
On Windows, the best way to check for errant DLL references is with
DEPENDS. I just checked my built fossil.exe, and DEPENDS lists only the
expected system libraries (ADVAPI32.DLL, KERNEL32.DLL, MSVCRT.DLL,
WS2_32.DLL) and no unexpected DLLs.
Things do get a little more interesting if you want to include OpenSSL
support...
--
Ross Berteig [email protected]
Cheshire Engineering Corp. http://www.CheshireEng.com/
_______________________________________________
fossil-users mailing list
[email protected]
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
