Re: [fossil-users] mingw doesn't build anymore on win8-64bit
2013/10/11 Martin Gagnon eme...@gmail.com: Finally, I found that your change in config.h fix the problem on some source files, but some source files include some system header files before the config.h (some even doesn't include config.h). I tried to fix this by making sure that every source include config.h before any other includes, but I got stuck when I go the error from sqlite3.c Probalby we need solution other than the #undef in the config.h... what do you think ? I'm open to any better solution, but I don't have any idea how to check in Makefile.mingw whether gcc produces 32-bit or 64-bit executables, that's why I came up with this #undef. I only have a 32-bit mingw compiler (or 64-bit cross-compiled mingw-w64), so I cannot really test it. Anyway I'll have another look. Thanks! Jan Nijtmans ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] mingw doesn't build anymore on win8-64bit
2013/10/11 Jan Nijtmans jan.nijtm...@gmail.com:
2013/10/11 Martin Gagnon eme...@gmail.com:
I tried to fix this by making sure that every source include config.h
before any other includes, but I got stuck when I go the error from
sqlite3.c
Thanks! Fixed now. I was able to reproduce your problem using
MinGW-w64 setting MINGW_IS_32BIT_ONLY (even though
MinGW-w64 doesn't need that)
Probalby we need solution other than the #undef in the config.h... what
do you think ?
Compiling the current trunk almost works. I get:
x86_64-w64-mingw32-gcc -Os -Wall -Lsrc/../compat/zlib
-Isrc/../compat/zlib -DBROKEN_MINGW_CMDLINE=1 -D_USE_32BIT_TIME_T -I.
-Isrc -DSQLITE_OMIT_LOAD_EXTENSION=1 -DSQLITE_THREADSAFE=0
-DSQLITE_DEFAULT_FILE_FORMAT=4 -DSQLITE_ENABLE_STAT3
-Dlocaltime=fossil_localtime -DSQLITE_ENABLE_LOCKING_STYLE=0
-DSQLITE_WIN32_NO_ANSI -D_HAVE_SQLITE_CONFIG_H -c src/sqlite3.c -o
wbld/sqlite3.o
x86_64-w64-mingw32-gcc -Os -Wall -Lsrc/../compat/zlib
-Isrc/../compat/zlib -DBROKEN_MINGW_CMDLINE=1 -D_USE_32BIT_TIME_T -I.
-Isrc -Dmain=sqlite3_shell -DSQLITE_OMIT_LOAD_EXTENSION=1
-D_HAVE_SQLITE_CONFIG_H -c src/shell.c -o wbld/shell.o
In file included from
/usr/x86_64-w64-mingw32/sys-root/mingw/include/crtdefs.h:10:0,
from /usr/x86_64-w64-mingw32/sys-root/mingw/include/stdlib.h:9,
from src/shell.c:31:
/usr/x86_64-w64-mingw32/sys-root/mingw/include/_mingw.h:456:2: error:
#error You cannot use 32-bit time_t (_USE_32BIT_TIME_T) with _WIN64
#error You cannot use 32-bit time_t (_USE_32BIT_TIME_T) with _WIN64
^
win/Makefile.mingw:1698: recipe for target `wbld/shell.o' failed
make: *** [wbld/shell.o] Error 1
Adding a #include config.h in shell.c and continuing, then still fails:
wbld/sqlite3.o:sqlite3.c:(.text+0xd2bb): undefined reference to
`sqlite3_version'
wbld/sqlite3.o:sqlite3.c:(.text+0xf2b5): undefined reference to
`sqlite3_version'
/usr/lib/gcc/x86_64-w64-mingw32/4.8.1/../../../../x86_64-w64-mingw32/bin/ld:
wbld/sqlite3.o: bad reloc address 0x18 in section `.data'
collect2: error: ld returned 1 exit status
win/Makefile.mingw:693: recipe for target `fossil.exe' failed
make: *** [fossil.exe] Error 1
The latter I don't understand, but below is a patch for SQLite which
fixes both of those problems. I didn't patch sqlite3.c and shell.c,
because the change would be lost whenever a new SQLite
version is copied into Fossil. But I hope that this patch
(or an alternative solution) will be evaluated in time for SQLite 3.8.1
Thanks!
Regards,
Jan Nijtmans
=
Index: src/main.c
==
--- src/main.c
+++ src/main.c
@@ -34,11 +34,11 @@
#endif
/* IMPLEMENTATION-OF: R-53536-42575 The sqlite3_libversion() function returns
** a pointer to the to the sqlite3_version[] string constant.
*/
-const char *sqlite3_libversion(void){ return sqlite3_version; }
+const char *sqlite3_libversion(void){ return SQLITE_VERSION; }
/* IMPLEMENTATION-OF: R-63124-39300 The sqlite3_sourceid() function returns a
** pointer to a string constant whose value is the same as the
** SQLITE_SOURCE_ID C preprocessor macro.
*/
Index: src/shell.c
==
--- src/shell.c
+++ src/shell.c
@@ -26,10 +26,18 @@
# define _FILE_OFFSET_BITS 64
# endif
# define _LARGEFILE_SOURCE 1
#endif
+/*
+** Include the configuration header output by 'configure' if we're using the
+** autoconf-based build
+*/
+#ifdef _HAVE_SQLITE_CONFIG_H
+#include config.h
+#endif
+
#include stdlib.h
#include string.h
#include stdio.h
#include assert.h
#include sqlite3.h
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] mingw doesn't build anymore on win8-64bit
On Fri, Oct 11, 2013 at 10:50:29AM +0200, Jan Nijtmans wrote: 2013/10/11 Jan Nijtmans jan.nijtm...@gmail.com: 2013/10/11 Martin Gagnon eme...@gmail.com: I tried to fix this by making sure that every source include config.h before any other includes, but I got stuck when I go the error from sqlite3.c Thanks! Fixed now. I was able to reproduce your problem using MinGW-w64 setting MINGW_IS_32BIT_ONLY (even though MinGW-w64 doesn't need that) Probalby we need solution other than the #undef in the config.h... what do you think ? Compiling the current trunk almost works. I get: Would it work to do the opposite way by not defining _USE_32BIT_TIME_T from the Makefile, and defining it under a #ifdef _WIN64 in the config.h ? What do you think ? -- Martin G. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] mingw doesn't build anymore on win8-64bit
2013/10/11 Martin Gagnon eme...@gmail.com: Would it work to do the opposite way by not defining _USE_32BIT_TIME_T from the Makefile, and defining it under a #ifdef _WIN64 in the config.h ? What do you think ? Yes, that looks better. And it indeed makes things simpler. Why didn't I think of that ;-) ... Unfortunately, it only fixes one of the two problems, and it breaks the normal MinGW build. See below for the log. See:http://fossil-scm.org/index.html/info/e25410039d Yes I think this is an improvement, but still not enough. ;-( Thanks! Any more ideas, other than patching SQLite? Jan Nijtmans gcc -Os -Wall -Lsrc/../compat/zlib -Isrc/../compat/zlib -DBROKEN_MINGW_CMDLINE=1 -o fossil.exe wbld/add.o wbld/allrepo.o wbld/attach.o wbld/bag.o wbld/bisect.o wbld/blob.o wbld/branch.o wbld/browse.o wbld/captcha.o wbld/cgi.o wbld/checkin.o wbld/checkout.o wbld/clearsign.o wbld/clone.o wbld/comformat.o wbld/configure.o wbld/content.o wbld/db.o wbld/delta.o wbld/deltacmd.o wbld/descendants.o wbld/d iff.o wbld/diffcmd.o wbld/doc.o wbld/encode.o wbld/event.o wbld/export.o wbld/fi le.o wbld/finfo.o wbld/glob.o wbld/graph.o wbld/gzip.o wbld/http.o wbld/http_soc ket.o wbld/http_ssl.o wbld/http_transport.o wbld/import.o wbld/info.o wbld/json. o wbld/json_artifact.o wbld/json_branch.o wbld/json_config.o wbld/json_diff.o wb ld/json_dir.o wbld/json_finfo.o wbld/json_login.o wbld/json_query.o wbld/json_re port.o wbld/json_status.o wbld/json_tag.o wbld/json_timeline.o wbld/json_user.o wbld/json_wiki.o wbld/leaf.o wbld/login.o wbld/lookslike.o wbld/main.o wbld/mani fest.o wbld/markdown.o wbld/markdown_html.o wbld/md5.o wbld/merge.o wbld/merge3. o wbld/moderate.o wbld/name.o wbld/path.o wbld/pivot.o wbld/popen.o wbld/pqueue. o wbld/printf.o wbld/rebuild.o wbld/regexp.o wbld/report.o wbld/rss.o wbld/schem a.o wbld/search.o wbld/setup.o wbld/sha1.o wbld/shun.o wbld/skins.o wbld/sqlcmd. o wbld/stash.o wbld/stat.o wbld/style.o wbld/sync.o wbld/tag.o wbld/tar.o wbld/t h_main.o wbld/timeline.o wbld/tkt.o wbld/tktsetup.o wbld/undo.o wbld/unicode.o w bld/update.o wbld/url.o wbld/user.o wbld/utf8.o wbld/util.o wbld/verify.o wbld/v file.o wbld/wiki.o wbld/wikiformat.o wbld/winhttp.o wbld/wysiwyg.o wbld/xfer.o w bld/xfersetup.o wbld/zip.o wbld/sqlite3.o wbld/shell.o wbld/th.o wbld/th_lang .o wbld/cson_amalgamation.o -static -lmingwex -lz -lkernel32 -lws2_32 wbld/foss il.o wbld/sqlite3.o:sqlite3.c:(.text+0xcd3a): undefined reference to `sqlite3_version ' wbld/sqlite3.o:sqlite3.c:(.text+0xec98): undefined reference to `sqlite3_version ' c:/mingw/bin/../lib/gcc/mingw32/4.8.1/../../../../mingw32/bin/ld.exe: wbld/sqlit e3.o: bad reloc address 0xc in section `.data' c:/mingw/bin/../lib/gcc/mingw32/4.8.1/../../../../mingw32/bin/ld.exe: final link failed: Invalid operation collect2.exe: error: ld returned 1 exit status make: *** [fossil.exe] Error 1 ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] mingw doesn't build anymore on win8-64bit
2013/10/11 Jan Nijtmans jan.nijtm...@gmail.com: Yes, that looks better. And it indeed makes things simpler. Why didn't I think of that ;-) ... Unfortunately, it only fixes one of the two problems, and it breaks the normal MinGW build. See below for the log. I finally figured it out. Fix is here: http://fossil-scm.org/index.html/info/0d70a87234 The problem was that including config.h in sqlite3.c (through the Makefile option -D_HAVE_SQLITE_CONFIG_H), includes sqlite3.h in turn. But sqlite3.h is already copied into sqlite3.c, with some changes. One of the changes is sqlite3_version, which is declared SQLITE_EXTERN there. This was the problem! The solution is not including sqlite3.h from config.h if this is done from the SQLite amalgamation. No changes to SQLite are needed for this (which would have been strange anyway) Thank you very much for your report and your input! All should be fine now. Regards, Jan Nijtmans ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] mingw doesn't build anymore on win8-64bit
On Fri, Oct 11, 2013 at 8:46 AM, Jan Nijtmans jan.nijtm...@gmail.comwrote: 2013/10/11 Jan Nijtmans jan.nijtm...@gmail.com: Yes, that looks better. And it indeed makes things simpler. Why didn't I think of that ;-) ... Unfortunately, it only fixes one of the two problems, and it breaks the normal MinGW build. See below for the log. I finally figured it out. Fix is here: http://fossil-scm.org/index.html/info/0d70a87234 The problem was that including config.h in sqlite3.c (through the Makefile option -D_HAVE_SQLITE_CONFIG_H), includes sqlite3.h in turn. But sqlite3.h is already copied into sqlite3.c, with some changes. But the content of sqlite3.h is protected from multiple inclusion using #ifndef _SQLITE3_H_ #define _SQLITE3_H_ ... #endif This protection occurs both in sqlite3.h and sqlite3.c. So why does having #include sqlite3.h in config.h matter? One of the changes is sqlite3_version, which is declared SQLITE_EXTERN there. This was the problem! The solution is not including sqlite3.h from config.h if this is done from the SQLite amalgamation. No changes to SQLite are needed for this (which would have been strange anyway) Thank you very much for your report and your input! All should be fine now. Regards, Jan Nijtmans ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users -- D. Richard Hipp d...@sqlite.org ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] mingw doesn't build anymore on win8-64bit
2013/10/11 Richard Hipp d...@sqlite.org: But the content of sqlite3.h is protected from multiple inclusion using #ifndef _SQLITE3_H_ #define _SQLITE3_H_ ... #endif This protection occurs both in sqlite3.h and sqlite3.c. So why does having #include sqlite3.h in config.h matter? It's tricky, indeed. It took some time for me to understand it It should be the same whether sqlite3.h is included or not, but the copy in sqlite3.c makes some modifications. Those modifications are causing the problem. In sqlite3.h I see: http://fossil-scm.org/index.html/artifact/d3177c3984?ln=144 But the copy in sqlite3.c: http://fossil-scm.org/index.html/artifact/70fe0ee1e6?ln=693 The only difference is the SQLITE_EXTERN. If sqlite3.h is included, then the symbol sqlite_version[] is assumed to exist somewhere else, but if the copy in sqlite3.c is used, the variable is created. The conclusion is that the amalgamation sqlite3.c cannot be compiled with the option -D_HAVE_SQLITE_CONFIG_H if config.h includes sqlite3.h. I don't think anyone ever tried to do that. I wouldn't recommend anyone to try it: sqlite3.c should take care of its own includes, no special options should be needed. But working around Microsoft's time_t tricks this looks like the best solution here. Regards, Jan Nijtmans ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] mingw doesn't build anymore on win8-64bit
On Fri, Oct 11, 2013 at 02:46:28PM +0200, Jan Nijtmans wrote: 2013/10/11 Jan Nijtmans jan.nijtm...@gmail.com: Yes, that looks better. And it indeed makes things simpler. Why didn't I think of that ;-) ... Unfortunately, it only fixes one of the two problems, and it breaks the normal MinGW build. See below for the log. I finally figured it out. Fix is here: http://fossil-scm.org/index.html/info/0d70a87234 The problem was that including config.h in sqlite3.c (through the Makefile option -D_HAVE_SQLITE_CONFIG_H), includes sqlite3.h in turn. But sqlite3.h is already copied into sqlite3.c, with some changes. One of the changes is sqlite3_version, which is declared SQLITE_EXTERN there. This was the problem! The solution is not including sqlite3.h from config.h if this is done from the SQLite amalgamation. No changes to SQLite are needed for this (which would have been strange anyway) Thank you very much for your report and your input! All should be fine now. Thanks to you... I can confirm, it's now working on my setup.. Before you found a solution, I was thinking about a crazy idea to be able to know from the Makefile if we need to define or not _USE_32BIT_TIME_T. We could have a dummy source file (e.g. use_32bit_time_t.c) that we could compile and execute before to compile the real thing. (kind of pre-compile step like what translate does) and this small source file could just contain the following code: #if defined(_WIN32) !defined(_WIN64) printf(no); #else printf(yes); #endif (or it could use differnet return value instead of using stdout) From the the Makefile.mingw, we could use $(shell ./use_32bit_time_t) to get the needed information. So this way, the define would be done from the makefile, so order of includes wouldn't be important and sqlite amalgamation file could stay un-touched. But I agree that it might be a bit overkill ... Regards, -- Martin G. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] mingw doesn't build anymore on win8-64bit
2013/10/11 Jan Nijtmans jan.nijtm...@gmail.com: It should be the same whether sqlite3.h is included or not I tested the MinGW compile with the latest SQLite 3.8.1 beta. It works fine. Actually, including sqlite3.h before or after config.h doesn't make any difference: The only system include in sqlite3.h is stdarg.h, and this include is not affected by any of the defines in config.h (I don't expect the average reader to understand this sentence.) I don't know if there are any platforms where the behavior of stdarg.h must be modified by defines in config.h. If such platforms exist, the previous SQLite would be better. Otherwise, it doesn't make any difference. Regards, Jan Nijtmans ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] mingw doesn't build anymore on win8-64bit
Hi list.. I recently try to compile latest trunk and the build failed.. Since I was already using a version I compile myself from 1 or 2 month ago, I decide to do a bisect to find which commit break it. So here my bisect result: $ fossil bisect chart 1 BAD 2013-10-09 13:58:55 6981cc6851ed5f3a 3 BAD 2013-09-30 14:45:45 238c8dafd070b99a 5 BAD 2013-09-27 04:08:16 1a30da30db0b2385 7 BAD 2013-09-26 07:17:32 a8214df37230c2de 8 GOOD2013-09-26 06:58:59 f2ce2f80f43edd4e 9 CURRENT 2013-09-26 06:58:59 f2ce2f80f43edd4e 6 GOOD2013-09-25 23:56:32 6b58c67ed8f95c32 4 GOOD2013-09-19 11:18:33 add752453332cdc3 2 GOOD2013-09-16 20:01:07 b5141cb799cb20a2 It happens that the only difference between 7 and 8 is the Makefile for mingw which now define: -D_USE_32BIT_TIME_T According to the commit log, this change was fixing winxp build, but apparently it break my windows 8 64bit ones.. (may be windows 7 64 bit, I didn't try) Someone know how to test for windows version from the makefile and from which version this defined is not needed ? Meanwhile, I'll try to experiment when I will have a chance. thanks -- Martin G. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] mingw doesn't build anymore on win8-64bit
2013/10/10 Martin Gagnon eme...@gmail.com: It happens that the only difference between 7 and 8 is the Makefile for mingw which now define: -D_USE_32BIT_TIME_T This define should only be used for a 32-bit build, never for 64-bit, so this is indeed a bug. I'll have a look how to fix this. Thanks! Regards, Jan Nijtmans ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] mingw doesn't build anymore on win8-64bit
2013/10/10 Jan Nijtmans jan.nijtm...@gmail.com: 2013/10/10 Martin Gagnon eme...@gmail.com: It happens that the only difference between 7 and 8 is the Makefile for mingw which now define: -D_USE_32BIT_TIME_T This define should only be used for a 32-bit build, never for 64-bit, so this is indeed a bug. I'll have a look how to fix this. Should be fine now: http://fossil-scm.org/index.html/info/d66cfb164f Regards, Jan Nijtmans ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] mingw doesn't build anymore on win8-64bit
On Thu, Oct 10, 2013 at 04:39:03PM +0200, Jan Nijtmans wrote: 2013/10/10 Jan Nijtmans jan.nijtm...@gmail.com: 2013/10/10 Martin Gagnon eme...@gmail.com: It happens that the only difference between 7 and 8 is the Makefile for mingw which now define: -D_USE_32BIT_TIME_T This define should only be used for a 32-bit build, never for 64-bit, so this is indeed a bug. I'll have a look how to fix this. Should be fine now: http://fossil-scm.org/index.html/info/d66cfb164f Still doesn't work, but I get different error: -- In file included from c:/msys/mingw-x64/mingw64/x86_64-w64-mingw32/include/crtdefs.h:10:0, from c:/msys/mingw-x64/mingw64/x86_64-w64-mingw32/include/assert.h:15, from src/captcha.c:22: c:/msys/mingw-x64/mingw64/x86_64-w64-mingw32/include/_mingw.h:456:2: error: #error You cannot use 32-bit time_t (_USE_32BIT_TIME_T) with _WIN64 #error You cannot use 32-bit time_t (_USE_32BIT_TIME_T) with _WIN64 ^ make: *** [wbld/captcha.o] Error 1 -- Regards.. -- Martin G. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] mingw doesn't build anymore on win8-64bit
On Thu, Oct 10, 2013 at 04:39:03PM +0200, Jan Nijtmans wrote: 2013/10/10 Jan Nijtmans jan.nijtm...@gmail.com: 2013/10/10 Martin Gagnon eme...@gmail.com: It happens that the only difference between 7 and 8 is the Makefile for mingw which now define: -D_USE_32BIT_TIME_T This define should only be used for a 32-bit build, never for 64-bit, so this is indeed a bug. I'll have a look how to fix this. Should be fine now: http://fossil-scm.org/index.html/info/d66cfb164f Regards, Jan Nijtmans Finally, I found that your change in config.h fix the problem on some source files, but some source files include some system header files before the config.h (some even doesn't include config.h). I tried to fix this by making sure that every source include config.h before any other includes, but I got stuck when I go the error from sqlite3.c Probalby we need solution other than the #undef in the config.h... what do you think ? -- Martin G. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
