Closed GoogleCodeExporter closed 9 years ago
Hi.
Mosh depends on particular version of the libraries and build options.
What kind of trouble did you have about the libraries?
Original comment by hige...@gmail.com
on 20 Jun 2010 at 1:06
in source based distro (gentoo) are these libs in portage ... make it dynamic
load and use system ....
Original comment by mimi...@gmail.com
on 5 Jul 2010 at 6:03
I basically agree with you. But there are some reasons about bundling libraries.
Boehm GC:
We need properly configured (--enable-threads --disable-parallel-mark) Boehm GC
for mosh.
Gentoo can do that using USE=thread, but some package system (Cygwin) can't.
And shared-library version of Boehm GC will misbehave in some platform (Win32).
GTest:
GTest is not designed to share testing code with shared-library.
Current GTest is formed in only 2 files (gtest-all.cc and gtest.h using
fuse_gtest_files.py)
and we should use this feature.
Oniguruma bundling should be avoided. But personally, i'm not using oniguruma
feature at all and
i'm not sure about this.
Original comment by oku...@gmail.com
on 5 Jul 2010 at 12:55
Thank you okuoku. You're right.
Original comment by hige...@gmail.com
on 5 Jul 2010 at 2:33
its no problem specify mosh deps for package maintainers ...
Original comment by mimi...@gmail.com
on 6 Jul 2010 at 8:28
May you at least make the use of system libraries optional?
Original comment by ohnobinki
on 9 Jul 2010 at 2:16
i think
* (remove GTest distribution and use fused one)
* --with(out)-oniguruma= (or remove oniguruma entirely and migrate to (irregex) library)
* --with-cflags= (to disabling guess of CFLAGS/CXXFLAGS)
are needed when we adopt Gentoo portage, macports, ports, pkgsrc, .... (i will
try to persuade higepon later)
But i won't do that for BoehmGC. Using misconfigured BoehmGC will result
extremely strange
behavior.. Some interpreters like Gauche also include their own BoehmGC and we
should do so
(see #3). Some projects like w3m or inkscape don't include BoehmGC and they
have very lengthy discussions
about GC..
Original comment by oku...@gmail.com
on 9 Jul 2010 at 8:27
i forgot to mention about --with-gmp= is also needed when we adopt ports.
Original comment by oku...@gmail.com
on 9 Jul 2010 at 8:48
gtest-1.2.1 was removed and now it uses fused-src version.
http://github.com/okuoku/mosh/commit/0e468db7f2d51d708ac79ae5c5d2d2a36bc97a20
status:
oniguruma is going to be unbundled. now i'm working for it. (i will try to
persuade higepon later)
detail:
I'm preparing to allow linking against oniguruma and gmp in gcc fashion.
(i.e. if there is oniguruma-* directory in mosh source-tree, then build and
link against to that,
otherwise link against system library.)
gcc will do this for their rarely-installed prerequisites like gmp, mpfr and
mpc.
Original comment by oku...@gmail.com
on 13 Aug 2010 at 7:35
Is it possible for the ./configure script to perform sanity checks against a
system-installed boehm-gc if the user requests linking against it? For example,
you could check during ./configure that the GC_CreateThread() function is
available in -lgc.
You could run a test program during ./configiure to ensure that the GC_parallel
variable is 0 and also include runtime logic to bail if GC_parallel is nonzero.
Since parallel mark is only enabled if the envar GC_NPROC is nonzero, having
this be a runtime or ``make check'' test and not checking it during ./configure
seems more reasonable. Also, it seems a user would appreciate and desire
support for parallel-mark ;-).
If the above assumptions fail, mosh-scheme might fall back on compiling the
bundled version and, of course, properly hiding boehm-gc's symbols.
Original comment by ohnobinki
on 18 Aug 2010 at 3:04
> Is it possible for the ./configure script to perform sanity checks against a
system-installed boehm-gc
> if the user requests linking against it?
Yes, we can inspect user-installed boehm gc configuration by your proposed way.
But these checking will be somewhat platform-specific (e.g. GC_CreateThread for
win32, GC_pthread_create for pthread, etc.)
and some checks will brake cross-building.
ah, honestly, our implementation is not robust enough to support varying
configuration of GC.
in fact, you can use parallel-marking GC, but that performance will
significantly worse
(even if parallel marking compiled-in but disabled) than non-parallel-marking
GC.
because we will allocate too many small objects and enabling parallel-mark will
introduce
additional thread locks.
so, we prefer static configured GC over user-configured GC for now.
Original comment by oku...@gmail.com
on 18 Aug 2010 at 12:41
For info, this issue stalled a Debian attempt to package mosh last year.
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=537776
Original comment by amoe...@gmail.com
on 28 Aug 2010 at 10:33
status: at 0.2.6 release,
- oniguruma will be unbundled
- gtest distribution will be reduced (include gtest-all.cc and main, gtest.h
only).
Currently, we have no plan for supporting system provided Boehm GC.
At least, mosh's internal BoehmGC won't affect another program which uses
system provided Boehm GC. (the only(AFAIK) exception is FFI call to such
library)
Original comment by oku...@gmail.com
on 27 Sep 2010 at 3:32
Hi,
I have tried to patch mosh to build (statically) with the system libgc. It
built without any problems. I have run 'make check' on moshes built with
bundled and system libgc, and the results are identical test-wise. I was using
a libgc 6.8 from Debian that is built with these options:
--enable-cplusplus --disable-dependency-tracking --with-tags=CXX
As the test suite all ran the same as the bundled version, I would conclude
that this libgc will be usable to run mosh. Is that correct? Is there a test
that should trigger the buggy behaviour on an incorrectly configured libgc?
Original comment by amoe...@gmail.com
on 7 Feb 2011 at 5:21
Reopened. Now we are investigating use of system-provided boehm GC.
amoebae:
Thank you for your research.
> Is that correct?
I think so. Recently, I had reached same conclusion with dynamically linked
libgc in major linux distros and FreeBSD.
> Is there a test that should trigger the buggy behaviour on an incorrectly
configured libgc?
Unfortunately, no. I'm preparing for it.
Now we are planning to add an option for link against system provided libgc and
make it default
in Linux/FreeBSD(and NetBSD if I could port for it).
(Because I had received many request for it and it makes sense in these
platform.)
Original comment by oku...@gmail.com
on 7 Feb 2011 at 6:23
Well, we had introduced another GC related optimization and that needs
GC_DONT_ADD_BYTE_AT_END explicitly.
So i had decided to (re-)close this issue as WONTFIX and leave GC as-is.
Original comment by oku...@gmail.com
on 23 Apr 2011 at 7:38
Original issue reported on code.google.com by
mimi...@gmail.com
on 19 Jun 2010 at 9:31