[fossil-users] Latest stable release or dev release does not compile with option: --static
Hello, Latest stable release or dev release does not compile with option: --static This issue occur with/without openSSL. I would like to point you out that readline is not used. Distribution : Porteus 1.2, 64bit. (Slackware based live CD) Latest stable release or dev release does not compile with option: --static This issue occur with/without openSSL. I would like to point you out that readline is not used. Distribution : Porteus 1.2, 64bit. (Slackware based live CD) Best Regards K.___ 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 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 > This issue occur with/without openSSL. > 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
Re: [fossil-users] Latest stable release or dev release does not compile with option: --static
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() - 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
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 : > [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 , 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 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. -- - 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 :
> On Wed, Jan 30, 2013 at 11:10 AM, Jan Nijtmans
> 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 wrote: > 2013/1/30 Sergei Gavrikov : > > [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 , 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 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) > 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 wrote: > > > On Wed, Jan 30, 2013 at 8:11 AM, Jan Nijtmans > wrote: >> >> 2013/1/30 Sergei Gavrikov : >> > [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 , 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 wrote: > > > On Wed, Jan 30, 2013 at 8:11 AM, Jan Nijtmans > wrote: >> >> 2013/1/30 Sergei Gavrikov : >> > [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 , 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 : > 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" wrote: 2013/1/30 Richard Hipp : > 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 wrote: > 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
Re: [fossil-users] Latest stable release or dev release does not compile with option: --static
On Wed, Jan 30, 2013 at 2:58 PM, Stephan Beal wrote: > On Wed, Jan 30, 2013 at 8:45 PM, Sergei Gavrikov > wrote: >> >> 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 It not only made those problems go away, but it also improved system performance, particularly boot times, because the common code (the libraries) got loaded once instead of once per-executable. The problems that Solaris 9 and earlier had with mixed dynamic and static linking are shockingly similar to problems one sees on Linux today. The typical example is a program that is single threaded and linked statically with libc but also with libdl, and then some part of the program ends up doing a dlopen() of a library that needs pthreads. Interesting things happen then. A number of Solaris 9 system libraries had lots of code whose only purpose was to deal with the transition from one process model (single-threaded) to the another (multi-threaded), occasioned by the loading of a dynamic shared library. This doesn't mean that you shouldn't want or can't have static linking. It means you shouldn't insist on statically linking *system* libraries, but you can have libsqlite3.a. Also, the main problem that arises from using dynamic linking is DLL hell. The simplest solution to that is direct binding (Solaris) or versioned symbols (Linux) -- you get static link semantics (no DLL hell) with the benefits of dynamic linking (such as not having to rebuild to benefit from a bug fix in a library, as well as explicit interposition via LD_PPRELOAD, and overall performance improvements). Nico -- ___ 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 : > 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
Re: [fossil-users] Latest stable release or dev release does not compile with option: --static
Hello everyone, Can't we use GnuTLS instead of openSSL ? Wget decided to use GnuTLS instead of openSSL... Best Regards K. D. Richard Hipp wrote: 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. > 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?___ 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
Hello all of you, 1/ Jan Nijtmans wrote: >I agree with others' remarks, that --static doesn't >make sense on modern systems any more. I do not agree with such statement. Static is important because mostly we do use two or more systems. (debian and centos for example) Darcs is static and runs everywhere... (at least for me) 2/ serious issue I've downloaded today's timeline trunk: $ ./configure --prefix=/usr --sysconfdir=/etc \ --with-openssl=none \ --static \ --json \ --markdown $ make ## all seems ok ! $ sudo make install $ fossil open fossil.fossil $ fossil update Autosync: http://www2.fossil-scm.org/ Segmentation faultrtifacts sent: 0 received: 0 $ fossil close fossil.fossil ## delete all the files... $ ./configure --prefix=/usr --sysconfdir=/etc \ --with-openssl=none \ --json \ --markdown $ make make: *** No rule to make target `src/../manifest.uuid', needed by `bld/VERSION.h'. Stop. ## delete all the files... ## install OpenSSL... $ ./configure --prefix=/usr --sysconfdir=/etc \ --with-openssl=none \ --json \ --markdown $ make ## ... HTTPS support enabled Checking for readline/readline.h...not found Checking for editline/readline.h...not found Checking libs for gethostbyname...none needed Checking libs for socket...none needed Checking libs for iconv...none needed Checking for getpassphrase...not found Checking libs for getpass...none needed Checking libs for dlopen...-ldl Created Makefile from Makefile.in Created autoconfig.h make: *** No rule to make target `src/../manifest.uuid', needed by `bld/VERSION.h'. Stop. If someone could explain me it would be great. I've seen these issues yesterday, however I decided to wait today for another more recent source. (fossil update) Best Regards K. Jan Nijtmans wrote: 2013/1/30 Jan Nijtmans : > 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 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 Thu, Jan 31, 2013 at 9:35 PM, K. Fossil user < ticketpersonnal-fos...@yahoo.fr> wrote: > I've downloaded today's timeline trunk: > ...$ fossil open fossil.fossil > $ fossil update > Autosync: http://www2.fossil-scm.org/ > Segmentation faultrtifacts sent: 0 received: 0 > Can you give us more info on that, e.g. the version hash and perhaps a stacktrace? i've been using several builds from today, built with both tcc and gcc, on i386 and x64 platforms with no such problems (also updating from the same source as you). > make: *** No rule to make target `src/../manifest.uuid', needed by > `bld/VERSION.h'. Stop. > That one i haven't seen in such a long time that i don't recall what caused it nor how to fix it :/. > If someone could explain me it would be great. > The following is from a very old post by Joe Mistachkin: --- A temporary workaround for this issue is to clone (or update) the Fossil source code and update to the release tag: fossil update release Then, while still in the Fossil source code directory, run: fossil set manifest on This should give you the correct "manifest" and "manifest.uuid" files needed to build the source code. -- I've seen these issues yesterday, however I decided to wait today for > another more recent source. > (fossil update) > That one with manifest.uuid has come up several times before, but i thought it had long since been solved. i unfortunately don't remember what causes it, though. Ooops... but now i've got my tree in that same state (and, even worse, my only fossil binary is (was) the one from that tree, so i've got a chicken/egg problem here). -- - 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
Hello, copy error in my last mail: correct copy is below : $ ./configure --prefix=/usr --sysconfdir=/etc \ --with-openssl=auto \ --json \ --markdown $ make ## ... HTTPS support enabled Checking for readline/readline.h...not found Checking for editline/readline.h...not found Checking libs for gethostbyname...none needed Checking libs for socket...none needed Checking libs for iconv...none needed Checking for getpassphrase...not found Checking libs for getpass...none needed Checking libs for dlopen...-ldl Created Makefile from Makefile.in Created autoconfig.h make: *** No rule to make target `src/../manifest.uuid', needed by `bld/VERSION.h'. Stop. Best Regards K.___ 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
$ fossil update ba86c859df checkout: ba86c859dff83e89640091ea18dec5571630af2a 2013-01-31 18:12:54 UTC tags: trunk comment: Added an "extern" to work around a duplicate-definition linking error with the tcc compiler. (user: stephan) changes: None. Already up-to-date $ fossil set manifest on $ ./configure --prefix=/usr --sysconfdir=/etc \ --with-openssl=auto \ --json \ --markdown $ make ## all compiles correctly, but next is a new issue: $ ./configure --prefix=/usr --sysconfdir=/etc \ --with-openssl=none \ --static \ --json \ --markdown $ make ## ... cc -DFOSSIL_ENABLE_JSON -DFOSSIL_ENABLE_MARKDOWN -g -O2 -DHAVE_AUTOCONFIG_H -I. -I./src -Ibld -DSQLITE_OMIT_LOAD_EXTENSION=1 -DSQLITE_THREADSAFE=0 -DSQLITE_DEFAULT_FILE_FORMAT=4 -DSQLITE_ENABLE_STAT3 -Dlocaltime=fossil_localtime -DSQLITE_ENABLE_LOCKING_STYLE=0 -c ./src/sqlite3.c -o bld/sqlite3.o cc -DFOSSIL_ENABLE_JSON -DFOSSIL_ENABLE_MARKDOWN -g -O2 -DHAVE_AUTOCONFIG_H -I. -I./src -Ibld -Dmain=sqlite3_shell -DSQLITE_OMIT_LOAD_EXTENSION=1 -c ./src/shell.c -o bld/shell.o cc -DFOSSIL_ENABLE_JSON -DFOSSIL_ENABLE_MARKDOWN -g -O2 -DHAVE_AUTOCONFIG_H -I. -I./src -Ibld -c ./src/th.c -o bld/th.o cc -DFOSSIL_ENABLE_JSON -DFOSSIL_ENABLE_MARKDOWN -g -O2 -DHAVE_AUTOCONFIG_H -I. -I./src -Ibld -c ./src/th_lang.c -o bld/th_lang.o cc -DFOSSIL_ENABLE_JSON -DFOSSIL_ENABLE_MARKDOWN -g -O2 -DHAVE_AUTOCONFIG_H -I. -I./src -Ibld -c ./src/cson_amalgamation.c -o bld/cson_amalgamation.o cc -DFOSSIL_ENABLE_JSON -DFOSSIL_ENABLE_MARKDOWN -g -O2 -DHAVE_AUTOCONFIG_H -o fossil bld/add.o bld/allrepo.o bld/attach.o bld/bag.o bld/bisect.o bld/blob.o bld/branch.o bld/browse.o bld/captcha.o bld/cgi.o bld/checkin.o bld/checkout.o bld/clearsign.o bld/clone.o bld/comformat.o bld/configure.o bld/content.o bld/db.o bld/delta.o bld/deltacmd.o bld/descendants.o bld/diff.o bld/diffcmd.o bld/doc.o bld/encode.o bld/event.o bld/export.o bld/file.o bld/finfo.o bld/glob.o bld/graph.o bld/gzip.o bld/http.o bld/http_socket.o bld/http_ssl.o bld/http_transport.o bld/import.o bld/info.o bld/json.o bld/json_artifact.o bld/json_branch.o bld/json_config.o bld/json_diff.o bld/json_dir.o bld/json_finfo.o bld/json_login.o bld/json_query.o bld/json_report.o bld/json_tag.o bld/json_timeline.o bld/json_user.o bld/json_wiki.o bld/leaf.o bld/login.o bld/main.o bld/manifest.o bld/markdown.o bld/markdown_html.o bld/md5.o bld/merge.o bld/merge3.o bld/moderate.o bld/name.o bld/path.o bld/pivot.o bld/popen.o bld/pqueue.o bld/printf.o bld/rebuild.o bld/regexp.o bld/report.o bld/rss.o bld/schema.o bld/search.o bld/setup.o bld/sha1.o bld/shun.o bld/skins.o bld/sqlcmd.o bld/stash.o bld/stat.o bld/style.o bld/sync.o bld/tag.o bld/tar.o bld/th_main.o bld/timeline.o bld/tkt.o bld/tktsetup.o bld/undo.o bld/unicode.o bld/update.o bld/url.o bld/user.o bld/utf8.o bld/verify.o bld/vfile.o bld/wiki.o bld/wikiformat.o bld/winhttp.o bld/wysiwyg.o bld/xfer.o bld/xfersetup.o bld/zip.o bld/sqlite3.o bld/shell.o bld/th.o bld/th_lang.o bld/cson_amalgamation.o -static -lz -ldl bld/shell.o: In function `find_home_dir': ./src/shell.c:2739: warning: Using 'getpwuid' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking bld/http_socket.o: In function `socket_open': ./src/http_socket.c:148: warning: Using 'gethostbyname' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking Best Regards K. Stephan Beal wrote: I've downloaded today's timeline trunk: >...$ fossil open fossil.fossil >$ fossil update >Autosync: http://www2.fossil-scm.org/ >Segmentation faultrtifacts sent: 0 received: 0 > Can you give us more info on that, e.g. the version hash and perhaps a stacktrace? i've been using several builds from today, built with both tcc and gcc, on i386 and x64 platforms with no such problems (also updating from the same source as you). make: *** No rule to make target `src/../manifest.uuid', needed by `bld/VERSION.h'. Stop. That one i haven't seen in such a long time that i don't recall what caused it nor how to fix it :/. If someone could explain me it would be great. The following is from a very old post by Joe Mistachkin: --- A temporary workaround for this issue is to clone (or update) the Fossil source code and update to the release tag: fossil update release Then, while still in the Fossil source code directory, run: fossil set manifest on This should give you the correct "manifest" and "manifest.uuid" files needed to build the source code. -- I've seen these issues yesterday, however I decided to wait today for another more recent source. >(fossil update) > That one with manifest.uuid has come up several times before, but i thought it had long since been solved. i unfortunately don't remember what causes it, though. Ooops... but now i've got my tree in
Re: [fossil-users] Latest stable release or dev release does not compile with option: --static
On Thu, Jan 31, 2013 at 3:19 PM, K. Fossil user wrote: > $ ./configure --prefix=/usr --sysconfdir=/etc \ > --with-openssl=auto \ > --json \ > --markdown > $ make > ./src/shell.c:2739: warning: Using 'getpwuid' in statically linked > applications requires at runtime the shared libraries from the glibc version > used for linking > bld/http_socket.o: In function `socket_open': > ./src/http_socket.c:148: warning: Using 'gethostbyname' in statically linked > applications requires at runtime the shared libraries from the glibc version > used for linking Well yes, using gethostbyname() and getpwuid() mean using dlopen() because that's what the name service switch in glibc does. If glibc were to always use nscd instead then this wouldn't happen. Anytime you need dlopen() you need all the run-time linker/loader machinery, and you need to be prepared to load libraries that need pthreads, and so on. Static linking is only really going to work well if you avoid dlopen() altogether. I don't understand the appeal of a binary that runs everywhere. Or, I do, but that's not easy anymore (and if you need multiple processor architectures then you really can't have this, not on Linux). On Solaris you can achieve that because of the ABI compatibility guarantee, as long as interfaces don't get EOFed on you. On Linux it ought to be the same, but because Linux depends on symbol versioning instead of direct binding, and because symbol versioning is typically added to libraries by the distros rather than by the open source projects themselves... you're at the mercy of the distros. If Linux were to adopt direct binding then all you'd need is common run-paths and SONAMEs, which you basically already get, and then it'd be a lot easier to build a single dynamic-linked executable that runs close enough to everywhere. ___ 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 Thu, Jan 31, 2013 at 10:19 PM, K. Fossil user < ticketpersonnal-fos...@yahoo.fr> wrote: > bld/shell.o: In function `find_home_dir': > ./src/shell.c:2739: warning: Using 'getpwuid' in statically linked > applications requires at runtime the shared libraries from the glibc > version used for linking > bld/http_socket.o: In function `socket_open': > ./src/http_socket.c:148: warning: Using 'gethostbyname' in statically > linked applications requires at runtime the shared libraries from the glibc > version used for linking > These we warned you about at the start of this thread - they are platform-specific limitations which we can do nothing to get rid of. -- - 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
On Thu, Jan 31, 2013 at 3:28 PM, Stephan Beal wrote:
> On Thu, Jan 31, 2013 at 10:19 PM, K. Fossil user
> wrote:
>>
>> bld/shell.o: In function `find_home_dir':
>> ./src/shell.c:2739: warning: Using 'getpwuid' in statically linked
>> applications requires at runtime the shared libraries from the glibc version
>> used for linking
>> bld/http_socket.o: In function `socket_open':
>> ./src/http_socket.c:148: warning: Using 'gethostbyname' in statically
>> linked applications requires at runtime the shared libraries from the glibc
>> version used for linking
>
>
> These we warned you about at the start of this thread - they are
> platform-specific limitations which we can do nothing to get rid of.
Wel, you could use getenv("USER") and LOGNAME instead of
getpwuid(), or fork/exec/spawn id(1) to get the username. And you
could use a DNS library to resolve the hostname without the benefit of
local caching (unless there's a local caching server).
The bigger problem is that this is something you'd risk having to do
again and again every time something else in glibc ends up needing
dlopen(). It's a losing battle, and even if it isn't (maybe nothing
else in glibc will ever need dlopen()), philosophically it is a losing
battle. So you have to build an executable per-distro -- welcome to
Linux.
Nico
--
___
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
1/ GLibc and linux symbols versionning issue then... OK, thanks. 2/ runs everywhere: I mean, it should run in every plateform... but not cross platform of course. It is not about java bytecode thing... :D For example, if someone do fossil compilation with i386, then ALL i386 linux should be able to run fossil with no changes. However, as you said it, we can't deal with that... Just too bad... Best Regards K. Nico Williams wrote: > $ ./configure --prefix=/usr --sysconfdir=/etc \ > --with-openssl=auto \ > --json \ > --markdown > $ make > ./src/shell.c:2739: warning: Using 'getpwuid' in statically linked > applications requires at runtime the shared libraries from the glibc version > used for linking > bld/http_socket.o: In function `socket_open': > ./src/http_socket.c:148: warning: Using 'gethostbyname' in statically linked > applications requires at runtime the shared libraries from the glibc version > used for linking Well yes, using gethostbyname() and getpwuid() mean using dlopen() because that's what the name service switch in glibc does. If glibc were to always use nscd instead then this wouldn't happen. Anytime you need dlopen() you need all the run-time linker/loader machinery, and you need to be prepared to load libraries that need pthreads, and so on. Static linking is only really going to work well if you avoid dlopen() altogether. I don't understand the appeal of a binary that runs everywhere. Or, I do, but that's not easy anymore (and if you need multiple processor architectures then you really can't have this, not on Linux). On Solaris you can achieve that because of the ABI compatibility guarantee, as long as interfaces don't get EOFed on you. On Linux it ought to be the same, but because Linux depends on symbol versioning instead of direct binding, and because symbol versioning is typically added to libraries by the distros rather than by the open source projects themselves... you're at the mercy of the distros. If Linux were to adopt direct binding then all you'd need is common run-paths and SONAMEs, which you basically already get, and then it'd be a lot easier to build a single dynamic-linked executable that runs close enough to everywhere.___ 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
>So you have to build an executable per-distro -- welcome to
>Linux.
Is it the same with *BSD systems ?
(Thank you for your tought: it's really appreciated !)
Best Regards
K.
Nico Williams wrote:
>>
>> bld/shell.o: In function `find_home_dir':
>> ./src/shell.c:2739: warning: Using 'getpwuid' in statically linked
>> applications requires at runtime the shared libraries from the glibc version
>> used for linking
>> bld/http_socket.o: In function `socket_open':
>> ./src/http_socket.c:148: warning: Using 'gethostbyname' in statically
>> linked applications requires at runtime the shared libraries from the glibc
>> version used for linking
>
>
> These we warned you about at the start of this thread - they are
> platform-specific limitations which we can do nothing to get rid of.
Wel, you could use getenv("USER") and LOGNAME instead of
getpwuid(), or fork/exec/spawn id(1) to get the username. And you
could use a DNS library to resolve the hostname without the benefit of
local caching (unless there's a local caching server).
The bigger problem is that this is something you'd risk having to do
again and again every time something else in glibc ends up needing
dlopen(). It's a losing battle, and even if it isn't (maybe nothing
else in glibc will ever need dlopen()), philosophically it is a losing
battle. So you have to build an executable per-distro -- welcome to
Linux.
Nico___
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 01:33:24PM -0500, Richard Hipp wrote: > For example, OpenSSL seems to not support static linking. OpenSSL only needs dynamic linkage for additional engines, e.g. to interact with hardware acceleration devices. Otherwise it is perfectly fine to statically link it. 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
On Thu, Jan 31, 2013 at 08:34:13PM +, K. Fossil user wrote: > Can't we use GnuTLS instead of openSSL ? > Wget decided to use GnuTLS instead of openSSL... The only real improvement GNU TLS provides over OpenSSL is GPL compatibility for Linux distributions. Otherwise it is just as messy as OpenSSL. Whether GPL compatibility is useful is a separate question and shouldn't be discussed on this list. 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
On 1/31/2013 12:35 PM, K. Fossil user wrote: Hello all of you, Hello. 2/ serious issue I've downloaded today's timeline trunk: $ ./configure --prefix=/usr --sysconfdir=/etc \ --with-openssl=none \ --static \ --json \ --markdown $ make ## all seems ok ! $ sudo make install $ fossil open fossil.fossil $ fossil update Autosync: http://www2.fossil-scm.org/ Segmentation faultrtifacts sent: 0 received: 0 I'd guess that it's crashing in the DNS resolver, although I wouldn't expect it to crash if it is running on the same host it was built on. I played with the static linking stuff a while back and I think I saw this behavior when I compiled on a 64 bit Ubuntu and ran on a 32 bit, or something like that. $ fossil close fossil.fossil The "fossil close" caused the problem below... ## delete all the files... $ ./configure --prefix=/usr --sysconfdir=/etc \ --with-openssl=none \ --json \ --markdown $ make make: *** No rule to make target `src/../manifest.uuid', needed by `bld/VERSION.h'. Stop. If a repository's "manifest" setting is on then the "manifest" and "manifest.uuid" files are included in the checkout directory when a repository is opened with "fossil open" (and in the files created by the "fossil zip" and "fossil tarball" commands). But they're removed by "fossil close". Fossil requires the "manifest" and "manifest.uuid" files to build, so you'll need to get them back. Running "fossil open" again would probably do it. -- Edward Berner ___ 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
* Richard Hipp [20130130 19:31]: > 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? Since no one has mentioned them yet, I wonder if using dropbear/libtomcrypt would be an option? https://matt.ucc.asn.au/dropbear/dropbear.html http://libtom.org/?page=features&newsitems=5&whatfile=crypt There's also polarSSL (previously xyssl), but licensing issues should be considered: https://polarssl.org/foss-license-exception ___ 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 Fri, Feb 1, 2013 at 9:09 AM, Edward Berner wrote: > I'd guess that it's crashing in the DNS resolver, although I wouldn't > expect it to crash if it is running on the same host it was built on. I > played with the static linking stuff a while back and I think I saw this > behavior when I compiled on a 64 bit Ubuntu and ran on a 32 bit, or > something like that. > FWIW: i looked at an strace dump sent to me off-list and the crash was caused by an OOM result from an mmap() which tried to allocate >4GB of memory. i have seen such inexplicable "mis-allocations" in other software on systems which mix 32- and 64-bit libraries, which jives with your observations. -- - 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
Hello, 1/ Thank you very much Edward Berner. You rock my world. Of course, embedded system must use light libc... I've seen that some software uses dietlibc. In my point of view, static linking can be done in this area, so it will be easier to spread Fossil everywhere with network support. 2/ I find that strange that a software needs manifest fix to compile without errors. I agree with you that maybe it is what I've done (fossil close) that may did this... 3/ Could you help Fossil team with dietlibc ? 4/ Crashing... I do compile Fossil in Porteus to unsure that _if_ it is possible to compile in Porteus, it will be possible EVERYWHERE to compile it WITHOUT issues. I do use Porteus 64 bit for that purpose. And I do run the resulting binary in Porteus 64 bit either... :-) The "Crashing" thing occur when I do compile with --static option... 5/ Question: why is it a DNS resolver issue ? Best Regards K. Edward Berner wrote : I think that for static linking on Linux you may need to look at what the embedded Linux folks are doing. I think the alternate libc libraries (musl libc, uclibc, dietlibc, etc.) have static linking as an explicit design goal. -- Edward Berner On 1/31/2013 12:35 PM, K. Fossil user wrote: > Hello all of you, Hello. > 2/ serious issue > I've downloaded today's timeline trunk: > $ ./configure --prefix=/usr --sysconfdir=/etc \ > --with-openssl=none \ > --static \ > --json \ > --markdown > $ make > ## all seems ok ! > $ sudo make install > $ fossil open fossil.fossil > $ fossil update > Autosync: http://www2.fossil-scm.org/ > Segmentation faultrtifacts sent: 0 received: 0 I'd guess that it's crashing in the DNS resolver, although I wouldn't expect it to crash if it is running on the same host it was built on. I played with the static linking stuff a while back and I think I saw this behavior when I compiled on a 64 bit Ubuntu and ran on a 32 bit, or something like that. > $ fossil close fossil.fossil The "fossil close" caused the problem below... > > ## delete all the files... > > $ ./configure --prefix=/usr --sysconfdir=/etc \ > --with-openssl=none \ > --json \ > --markdown > $ make > make: *** No rule to make target `src/../manifest.uuid', needed by > `bld/VERSION.h'. Stop. If a repository's "manifest" setting is on then the "manifest" and "manifest.uuid" files are included in the checkout directory when a repository is opened with "fossil open" (and in the files created by the "fossil zip" and "fossil tarball" commands). But they're removed by "fossil close". Fossil requires the "manifest" and "manifest.uuid" files to build, so you'll need to get them back. Running "fossil open" again would probably do it. -- Edward Berner___ 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
Joerg Sonnenberger wrote: [...] > The only real improvement GNU TLS provides over OpenSSL is GPL > compatibility for Linux distributions. Otherwise it is just as messy as > OpenSSL. Having used it in a project, I would agree with that last statement, but I should point out that GNUTLS does provide one semi-interesting feature --- it allows the use of GPG keys as SSL certificates: http://gnutls.org/openpgp.html Of course, it's not compatible with any other implementation of SSL, but if people are interested in using a web-of-trust security model instead of the X509 sacred cow security model, it's a potential option. -- ┌─── ｄｇ＠ｃｏｗｌａｒｋ．ｃｏｍ ─ http://www.cowlark.com ─ │ │ 𝕻𝖍'𝖓𝖌𝖑𝖚𝖎 𝖒𝖌𝖑𝖜'𝖓𝖆𝖋𝖍 𝕮𝖙𝖍𝖚𝖑𝖍𝖚 𝕽'𝖑𝖞𝖊𝖍 𝖜𝖌𝖆𝖍'𝖓𝖆𝖌𝖑 𝖋𝖍𝖙𝖆𝖌𝖓. │ signature.asc Description: OpenPGP digital signature ___ 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 2/1/2013 3:15 PM, K. Fossil user wrote: Hello, 1/ Thank you very much Edward Berner. You rock my world. Of course, embedded system must use light libc... I've seen that some software uses dietlibc. In my point of view, static linking can be done in this area, so it will be easier to spread Fossil everywhere with network support. 2/ I find that strange that a software needs manifest fix to compile without errors. Fossil reads "manifest" and "manifest.uuid" at build time to gather some of the information displayed by the "fossil version" command. I agree with you that maybe it is what I've done (fossil close) that may did this... 3/ Could you help Fossil team with dietlibc ? I got curious and played with musl libc. It was pretty straight forward; I'll post a summary in another message. I wouldn't recommend static binaries for general use, however, since they don't work with some things, such as Pluggable Authentication Modules and the Name Service Switch, which I feel are expected features in modern desktop and server Linux. 4/ Crashing... I do compile Fossil in Porteus to unsure that _if_ it is possible to compile in Porteus, it will be possible EVERYWHERE to compile it WITHOUT issues. I do use Porteus 64 bit for that purpose. And I do run the resulting binary in Porteus 64 bit either... :-) The "Crashing" thing occur when I do compile with --static option... 5/ Question: why is it a DNS resolver issue ? That's just a guess, based on two things: 1) It seemed to be a DNS resolver issue when I encountered a similar problem once upon a time, and 2) one of the warnings when building with "--static" is about the function "gethostbyname" which is part of the DNS resolver. -- Edward Berner ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
