Re: [fossil-users] Latest stable release or dev release does not compile with option: --static
On Wed, 30 Jan 2013, Jan Nijtmans wrote: 2013/1/29 Stephan Beal: On Tue, Jan 29, 2013 at 9:00 AM, K. Fossil user wrote: Latest stable release or dev release does not compile with option: --static ... Like networking libs, it will produce warnings like: warning: Using 'dlopen' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking Those are only warnings, the executable should work fine. I tried it, and encountered 2 minor problems on Linux: - strcmp from the static C library cannot be used, it should be replaced by fossil_strcmp everywhere. (that's a good idea anyway, as strcmp is locale-dependant) Fossil's TCL support also appears to use dlopen() [snip] The first problem is fixed now on trunk, the second one should be easy to fix (for someone who understands the build system better than I do). [FYI] An optimized (-O2) default build with entered substitution -Dstrcmp=fossil_strcmp fails (SIGSEG) on i686 GNU/Linux Reading symbols from /home/sg/fossil/build/fossil...done. (gdb) set args clean --force (gdb) run Starting program: /home/sg/fossil/build/fossil clean --force Program received signal SIGSEGV, Segmentation fault. fossil_strcmp (zA=0xb452 force, zB=0x0) at ../src/printf.c:908 908 b = *zB++; (gdb) bt #0 fossil_strcmp (zA=0xb452 force, zB=0x0) at ../src/printf.c:908 #1 0x0808d73c in find_option (zLong=0x815454b quiet, zShort=0x0, hasArg=0) at ../src/main.c:865 #2 0x080902ca in main (argc=3, argv=0xb294) at ../src/main.c:510 (gdb) detach Detaching from program: /home/sg/fossil/build/fossil, process 18084 (gdb) q % ./fossil version This is fossil version 1.25 [7ac0fd9d11] 2013-01-30 10:03:19 UTC The -O0 build does parse the same option without the issue. Sergei ___ 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] Latest stable release or dev release does not compile with option: --static
2013/1/30 Sergei Gavrikov sergei.gavri...@gmail.com: [FYI] An optimized (-O2) default build with entered substitution -Dstrcmp=fossil_strcmp fails (SIGSEG) on i686 GNU/Linux ... Program received signal SIGSEGV, Segmentation fault. ... Thanks! That's fully explainable: When setting -Dstrcmp=fossil_strcmp before including string.h, and strcmp has a decoration that its arguments are non-null, that is used by the optimizer to remove the two first if's from the fossil_strcmp function: if its arguments cannot be NULL, that's a valid optimization Should be fixed now, by #undef'fing fossil_strcmp in printf.c Many 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] Latest stable release or dev release does not compile with option: --static
On Wed, Jan 30, 2013 at 11:10 AM, Jan Nijtmans jan.nijtm...@gmail.comwrote: Fossil's TCL support also appears to use dlopen() - The link flag -ldl is missing on Linux. That's the shared library containing dlopen,so - indeed - without it, Tcl support will not work. Which flavour of linux are you on? On my Ubuntu 12.04 and 12.10 systems -ldl is being included in the linker flags. -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal ___ 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] Fix for wiki URL markup
On Wed, Jan 30, 2013 at 12:54 AM, David Given d...@cowlark.com wrote: (How does one go about submitting a contributor agreement?) Hi! http://www.fossil-scm.org/fossil/doc/trunk/www/copyright-release.html That needs to be printed out, filled out, and snail-mailed to the address at the bottom of the form. -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal ___ 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] Latest stable release or dev release does not compile with option: --static
2013/1/30 Stephan Beal sgb...@googlemail.com:
On Wed, Jan 30, 2013 at 11:10 AM, Jan Nijtmans jan.nijtm...@gmail.com
wrote:
Fossil's TCL support also appears to use dlopen()
- The link flag -ldl is missing on Linux. That's the shared library
containing dlopen,so - indeed - without it, Tcl support will not work.
Which flavour of linux are you on? On my Ubuntu 12.04 and 12.10 systems -ldl
is being included in the linker flags.
Looking at auto.def, the problem is with the with-tcl-stubs option:
set tclstubs [opt-bool with-tcl-stubs]
if {$tclstubs $tclconfig(TCL_SUPPORTS_STUBS)} {
set libs $tclconfig(TCL_STUB_LIB_SPEC)
define FOSSIL_ENABLE_TCL_STUBS
define USE_TCL_STUBS
} else {
set libs $tclconfig(TCL_LIB_SPEC) $tclconfig(TCL_LIBS)
}
The $tclconfig(TCL_LIBS) contains the -ldl, but
$tclconfig(TCL_STUB_LIB_SPEC) does not, which is
OK. (the stub library doesn't use dlopen, fossil does)
Somehow, fossil should add -ldl here, such that the
--with-tcl-stubs option works in combination with --static.
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] Latest stable release or dev release does not compile with option: --static
On Wed, Jan 30, 2013 at 8:11 AM, Jan Nijtmans jan.nijtm...@gmail.comwrote: 2013/1/30 Sergei Gavrikov sergei.gavri...@gmail.com: [FYI] An optimized (-O2) default build with entered substitution -Dstrcmp=fossil_strcmp fails (SIGSEG) on i686 GNU/Linux ... Program received signal SIGSEGV, Segmentation fault. ... Thanks! That's fully explainable: When setting -Dstrcmp=fossil_strcmp before including string.h, and strcmp has a decoration that its arguments are non-null, that is used by the optimizer to remove the two first if's from the fossil_strcmp function: if its arguments cannot be NULL, that's a valid optimization Should be fixed now, by #undef'fing fossil_strcmp in printf.c I'm uncomfortable with this change. If we need to use fossil_strcmp() everywhere (which surprises me, since strcmp() should *not* be subject to localization) then we should do so explicitly, and not depend on preprocessor magic, as the preprocessor magic will likely cause maintenance headaches down the road, and/or introduce subtle bugs such as the above. Many 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 -- 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] Latest stable release or dev release does not compile with option: --static
On Wed, Jan 30, 2013 at 5:10 AM, Jan Nijtmans jan.nijtm...@gmail.comwrote: 2013/1/29 Stephan Beal sgb...@googlemail.com: On Tue, Jan 29, 2013 at 9:00 AM, K. Fossil user ticketpersonnal-fos...@yahoo.fr wrote: Latest stable release or dev release does not compile with option: --static ... Like networking libs, it will produce warnings like: warning: Using 'dlopen' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking Those are only warnings, the executable should work fine. I tried it, and encountered 2 minor problems on Linux: - strcmp from the static C library cannot be used, it should be replaced by fossil_strcmp everywhere. (that's a good idea anyway, as strcmp is locale-dependant) I don't think so. Maybe you are thinking of strcasecmp(). strcmp() should not be locale-dependent and it should not cause static linkage problems on linux. The Fossil server on the fossil website is statically linked and it is running on Ubuntu - no problems at all. Fossil's TCL support also appears to use dlopen() - The link flag -ldl is missing on Linux. That's the shared library containing dlopen,so - indeed - without it, Tcl support will not work. The first problem is fixed now on trunk, the second one should be easy to fix (for someone who understands the build system better than I do). 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] Latest stable release or dev release does not compile with option: --static
While I agree that the -Dstrcmp... solution is inadequate, strcmp is subject to the system locale setting. While it might default to the C locale (giving the expected binary comparison behavior), it might not. One may not consider locale the same as localization, but whatever you choose to call it, it can result in non-deterministic behavior based on the exact system configuration. SDR On Wed, Jan 30, 2013 at 8:19 AM, Richard Hipp d...@sqlite.org wrote: On Wed, Jan 30, 2013 at 8:11 AM, Jan Nijtmans jan.nijtm...@gmail.com wrote: 2013/1/30 Sergei Gavrikov sergei.gavri...@gmail.com: [FYI] An optimized (-O2) default build with entered substitution -Dstrcmp=fossil_strcmp fails (SIGSEG) on i686 GNU/Linux ... Program received signal SIGSEGV, Segmentation fault. ... Thanks! That's fully explainable: When setting -Dstrcmp=fossil_strcmp before including string.h, and strcmp has a decoration that its arguments are non-null, that is used by the optimizer to remove the two first if's from the fossil_strcmp function: if its arguments cannot be NULL, that's a valid optimization Should be fixed now, by #undef'fing fossil_strcmp in printf.c I'm uncomfortable with this change. If we need to use fossil_strcmp() everywhere (which surprises me, since strcmp() should *not* be subject to localization) then we should do so explicitly, and not depend on preprocessor magic, as the preprocessor magic will likely cause maintenance headaches down the road, and/or introduce subtle bugs such as the above. Many 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 -- 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 ___ 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] Latest stable release or dev release does not compile with option: --static
And never mind, I guess I was wrong. Not sure why I couldn't have checked that *before* clicking send, but c'est la vie. SDR On Wed, Jan 30, 2013 at 8:19 AM, Richard Hipp d...@sqlite.org wrote: On Wed, Jan 30, 2013 at 8:11 AM, Jan Nijtmans jan.nijtm...@gmail.com wrote: 2013/1/30 Sergei Gavrikov sergei.gavri...@gmail.com: [FYI] An optimized (-O2) default build with entered substitution -Dstrcmp=fossil_strcmp fails (SIGSEG) on i686 GNU/Linux ... Program received signal SIGSEGV, Segmentation fault. ... Thanks! That's fully explainable: When setting -Dstrcmp=fossil_strcmp before including string.h, and strcmp has a decoration that its arguments are non-null, that is used by the optimizer to remove the two first if's from the fossil_strcmp function: if its arguments cannot be NULL, that's a valid optimization Should be fixed now, by #undef'fing fossil_strcmp in printf.c I'm uncomfortable with this change. If we need to use fossil_strcmp() everywhere (which surprises me, since strcmp() should *not* be subject to localization) then we should do so explicitly, and not depend on preprocessor magic, as the preprocessor magic will likely cause maintenance headaches down the road, and/or introduce subtle bugs such as the above. Many 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 -- 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 ___ 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] Latest stable release or dev release does not compile with option: --static
2013/1/30 Richard Hipp d...@sqlite.org: I'm uncomfortable with this change. If we need to use fossil_strcmp() everywhere (which surprises me, since strcmp() should *not* be subject to localization) then we should do so explicitly, and not depend on preprocessor magic, as the preprocessor magic will likely cause maintenance headaches down the road, and/or introduce subtle bugs such as the above. I'm open to other suggestions how to fix this. The problem was noticed on 64-bit Ubuntu, it might be 64-bit specific (I'm not near that machine now). I agree that it would be better to rename strcmp-fossil_strcmp everywhere, but I don't think you want to do that in sqlite as well, therefore I came up with the macro. 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] Latest stable release or dev release does not compile with option: --static
I'm not yet convinced this is a problem that needs fixing. D. Richard Hipp - d...@sqlite.org Sent from phone - pardon brevity On Jan 30, 2013 11:00 AM, Jan Nijtmans jan.nijtm...@gmail.com wrote: 2013/1/30 Richard Hipp d...@sqlite.org: I'm uncomfortable with this change. If we need to use fossil_strcmp() everywhere (which surpris... I'm open to other suggestions how to fix this. The problem was noticed on 64-bit Ubuntu, it might be 64-bit specific (I'm not near that machine now). I agree that it would be better to rename strcmp-fossil_strcmp everywhere, but I don't think you want to do that in sqlite as well, therefore I came up with the macro. Regards, Jan Nijtmans ___ fossil-users mailing... ___ 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] Latest stable release or dev release does not compile with option: --static
On Wed, 30 Jan 2013, Jan Nijtmans wrote:
2013/1/30 Richard Hipp wrote:
I'm uncomfortable with this change. If we need to use fossil_strcmp()
everywhere (which surprises me, since strcmp() should *not* be subject to
localization) then we should do so explicitly, and not depend on
preprocessor magic, as the preprocessor magic will likely cause maintenance
headaches down the road, and/or introduce subtle bugs such as the above.
I'm open to other suggestions how to fix this. The problem was noticed on
64-bit Ubuntu, it might be 64-bit specific (I'm not near that machine now).
I agree that it would be better to rename strcmp-fossil_strcmp everywhere,
but I don't think you want to do that in sqlite as well, therefore I came up
with the macro.
AFAIS, fossil_strcmp() != strcmp()
http://fossil-scm.org/index.html/artifact/eda142ab1e3e0a0213d522c5b7a22831023cab0f?ln=898-902
# plain STRCMP (3)
% for i in str{,n}cmp;do echo -n $i - ;grep $i src/*.c|egrep -v
(sqlite3|fossil)_$i|wc -l;done
strcmp - 143
strncmp - 210
I would undo magic and rename nothing :-)
Sergei
___
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] Latest stable release or dev release does not compile with option: --static
On Wed, Jan 30, 2013 at 11:10:46AM +0100, Jan Nijtmans wrote: and encountered 2 minor problems on Linux: - strcmp from the static C library cannot be used, it should be replaced by fossil_strcmp everywhere. (that's a good idea anyway, as strcmp is locale-dependant) No, it isn't. That's what strcoll(3) is for. Joerg ___ 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] Latest stable release or dev release does not compile with option: --static
-DLL = Windows. I do not use window$ -Warning does not stop compiling... :-) -Why do I ask for --static compilation to succeed Don't forget that if you would like Fossil to be used, it must be easy to compile, especially with option --static. People would like to use a DVCS everywhere with any distro with the SAME binary, not the one specific to a distro. Darcs, I've downloaded, runs everywhere... I do use at least, Linux Mint, Porteus, Slackware, CentOS, debian... Sometimes in Live CD mode sometimes not... Sometimes Ubuntu. Just sayin' BTW, Thanks to people who tries to fix this. Best Regards K. stephan beal wrote : On Linux the networking-related libraries cannot be statically linked (for reasons i once knew but no longer recall). Or they _can_ be linked but the linker will warn you that it's not _really_ statically linking them and that the DLL will be used at run-time. Fossil's TCL support also appears to use dlopen(), which cannot be used in statically-linked programs (at least on Linux). Like networking libs, it will produce warnings like: warning: Using 'dlopen' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users___ 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] Latest stable release or dev release does not compile with option: --static
On Wed, Jan 30, 2013 at 12:30 PM, K. Fossil user ticketpersonnal-fos...@yahoo.fr wrote: People would like to use a DVCS everywhere with any distro with the SAME binary, not the one specific to a distro. I concur. Unfortunately, this is a function of the distro more than of the application. For example, OpenSSL seems to not support static linking and is also highly distro-dependent, so a universal binary needs to omit HTTPS support. So there are tradeoffs. Fossil has traditionally worked great on all systems, directly from sources. And the binaries are highly portable (module OpenSSL issues). Have you seen otherwise? -- 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] Latest stable release or dev release does not compile with option: --static
On Wed, 30 Jan 2013, K. Fossil user wrote: People would like to use a DVCS everywhere with any distro with the SAME binary, not the one specific to a distro. First, I do not say that build process for a static executable should fail. But at least such process is not trivial (it was given a lot of reasons here). [FYI] Incidentally, there is another opinion, Never use static linking! http://www.akkadia.org/drepper/no_static_linking.html SYNOPSIS https://access.redhat.com/knowledge/docs/en-US/Red_Hat_Enterprise_Linux/6/html/Developer_Guide/lib.compatibility.static.html Sergei ___ 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] Latest stable release or dev release does not compile with option: --static
On Wed, Jan 30, 2013 at 8:45 PM, Sergei Gavrikov sergei.gavri...@gmail.comwrote: Incidentally, there is another opinion, Never use static linking! http://www.akkadia.org/drepper/no_static_linking.html On a related note, Solaris 10 removed static versions of their system libraries, due to a long history of statically-linked binaries causing (in the words of one of the articles below) pain and ruin: https://blogs.oracle.com/rie/entry/static_linking_where_did_it http://stackoverflow.com/questions/7024730/from-static-to-dynamic-linking-on-solaris-10 -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] Compile Fossil with Tiny C Compiler
Hi [The below is thanking -static issue] I search through the list for /Fabrice Bellard/ and found nothing. His famous Tiny C Compiler (http://en.wikipedia.org/wiki/Tiny_C_Compiler http://bellard.org/tcc/) is well-known in Tcl community and they know its strengths. I want to share here my 2-minutes experiment (below is cp from a terminal): Make the very virgin environment sg@...:build fossil clean -f sg@...:build ../configure --quiet --json --markdown sg@...:build ccache -Cc Cleared cache Cleaned cache Build Fossil with `tcc' and run it -- sg@...:build time make -s BCC=tcc TCC=tcc ./fossil version ../src/diffcmd.c:290: warning: assignment makes pointer from integer without a cast ../src/diffcmd.c:447: warning: assignment makes pointer from integer without a cast ../src/diffcmd.c:449: warning: assignment makes pointer from integer without a cast ../src/rebuild.c:849: warning: assignment from incompatible pointer type ../src/vfile.c:467: warning: assignment from incompatible pointer type ../src/sqlite3.c:20089: warning: assignment makes pointer from integer without a cast ../src/sqlite3.c:43635: warning: assignment makes pointer from integer without a cast real 0m1.926s user 0m1.776s sys 0m0.680s This is fossil version 1.25 [8027c7e648] 2013-01-30 18:14:26 UTC It took 2 seconds on my laptop and I've got working copy of Fossil! Make again a virgin --- sg@...:build ccache -Cc Cleared cache Cleaned cache sg@...:build make clean rm -rf bld/* fossil Build Fossil with `gcc' (no `ccache') and run it sg@...:build time make -s ./fossil version real 1m8.647s user 1m2.852s sys 0m4.760s This is fossil version 1.25 [8027c7e648] 2013-01-30 18:14:26 UTC Yep, it takes about 1 minute. So, I use `ccache'. Though, no warnings :-) Just clean (but do not break ccache caches) --- sg@...:build make clean rm -rf bld/* fossil Repeat build and run with `gcc' + `ccache' -- sg@...:build time make -s ./fossil version real 0m7.823s user 0m6.016s sys 0m1.784s This is fossil version 1.25 [8027c7e648] 2013-01-30 18:14:26 UTC It took ~8 seconds. What `tcc' I used here -- sg@...:build tcc -v tcc version 0.9.24 Afterwords -- I like to see how `tcc' compile sqlite3.c in a second :-) Why this here? IMHO, it is cool, and if you pack `jimsh0' with `autosetup', perhaps, some one can try to pack `tcc' with some ... autobuild. BTW, there is Windows binary distribution of `tcc': http://bellard.org/tcc/ http://download.savannah.nongnu.org/releases/tinycc/tcc-0.9.25-win32-bin.zip but, I have no chance to try it. WARNING! Thus, I installed the built fossil with `tcc' under /usr/local/bin, I do not test the build heavily! Regards, Sergei ___ 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] Compile Fossil with Tiny C Compiler
On Wed, Jan 30, 2013 at 10:29 PM, Sergei Gavrikov sergei.gavri...@gmail.com wrote: I search through the list for /Fabrice Bellard/ and found nothing. His famous Tiny C Compiler (http://en.wikipedia.org/wiki/Tiny_C_Compiler http://bellard.org/tcc/) is well-known in Tcl community and they know its strengths. It's funny you mention this now - the past week or two the tcc dev team has been collecting last-minute fixes for a new release (the first one in an obscenely long time). It took 2 seconds on my laptop and I've got working copy of Fossil! The current tcc release (0.9.25) fails on some 64-bit platforms with a 'missing stddef.h' error :(. sg@...:build tcc -v tcc version 0.9.24 0.9.26 should be released next Wednesday (according to list chatter). 0.9.25 is widespread on Linux platforms, but has a long history of compile-time errors on 64-bit platforms. The so-called mob branch (which fixes those problems) has been the unofficial trunk of tcc for at least a year or so, but no distro i'm aware of ships a version based on that branch. I like to see how `tcc' compile sqlite3.c in a second :-) On my old 32-bit/1.2GHz netbook tcc 0.9.25 compiles sqlite3 in 0.4 seconds :-D. gcc takes well over a minute. i've written the tcc team expressing my amazement at this type of result, but they respond to my excitement with a sober, but the runtime code is not as fast as gcc's. (Also, tcc's warning/error messages are, in general, not nearly as detailed.) Nonetheless, tcc's compile times are absolutely amazing - i regularly see 10x+ increases in compile speed with tcc. -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal ___ 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] Latest stable release or dev release does not compile with option: --static
2013/1/30 Jan Nijtmans jan.nijtm...@gmail.com: The $tclconfig(TCL_LIBS) contains the -ldl, but $tclconfig(TCL_STUB_LIB_SPEC) does not, which is OK. (the stub library doesn't use dlopen, fossil does) Somehow, fossil should add -ldl here, such that the --with-tcl-stubs option works in combination with --static. Regards, Jan Nijtmans Fix committed. On most platforms --static should work again. I still have problems on Ubuntu AMD64, when using --static in combination --with-tcl-stubs option (even with the fossil_strcmp macro), but I really wonder who would want this: A static fossil binary with dynamically loading libtcl I agree with others' remarks, that --static doesn't make sense on modern systems any more. 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] Proper use of revert
Hello - Yesterday I needed to revert back a commit involving 2 files to its parent commit. The working copy was at the tip (1255785c96) and I needed to get back to revision 4002407825. When I tried running fossil revert -r 4002407825 I got the following error: fossil: the --revision option does not work for the entire tree What did the trick was fossil merge --backout 1255785c96 which is strange, since this is not a merge. The timeline UI for this particular repo shows a straight line graph. Shouldn't the 'revert' command act the way I was looking for? The help message does state Revert all files if no file name is provided. What am I missing? Thanks, Arnel PS: Apologies if you've received this before. I sent this out to the list yesterday but I don't see it listed in the Fossil ML archives. ___ 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] Proper use of revert
On Wed, Jan 30, 2013 at 02:48:33PM -0800, Arnel Legaspi wrote: Hello - Yesterday I needed to revert back a commit involving 2 files to its parent commit. The working copy was at the tip (1255785c96) and I needed to get back to revision 4002407825. When I tried running fossil revert -r 4002407825 I got the following error: fossil: the --revision option does not work for the entire tree What did the trick was fossil merge --backout 1255785c96 which is strange, since this is not a merge. The timeline UI for this particular repo shows a straight line graph. Shouldn't the 'revert' command act the way I was looking for? The help message does state Revert all files if no file name is provided. What am I missing? Reverts removes changes in your *working directory*. It's not about reverting code already checked int. You want 'fossil merge -backout' I guess. The help for merge explains better. Regards, Lluís. ___ 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] Compile Fossil with Tiny C Compiler
On Wed, Jan 30, 2013 at 10:46 PM, Stephan Beal sgb...@googlemail.com wrote: i've written the tcc team expressing my amazement at this type of result, but they respond to my excitement with a sober, but the runtime code is not as fast as gcc's. (Also, tcc's warning/error messages are, in general, not nearly as detailed.) Nonetheless, tcc's compile times are absolutely amazing - i regularly see 10x+ increases in compile speed with tcc. I can understand tcc team answer, after all most of the users of a program do not see the compiling time. But it does sound cool for development! ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
