Please unbundle libs..

[GoogleCodeExporter]

Please unbundle Boehm-GC , GTest and Oniguruma from source code and build 
system ...

Use system libs instead ...

Original issue reported on code.google.com by mimi...@gmail.com on 19 Jun 2010 at 9:31

[GoogleCodeExporter]

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

• Changed state: Accepted

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

[GoogleCodeExporter]

Thank you okuoku. You're right.

Original comment by hige...@gmail.com on 5 Jul 2010 at 2:33

• Changed state: WontFix

[GoogleCodeExporter]

its no problem specify mosh deps for package maintainers ...

Original comment by mimi...@gmail.com on 6 Jul 2010 at 8:28

[GoogleCodeExporter]

May you at least make the use of system libraries optional?

Original comment by ohnobinki on 9 Jul 2010 at 2:16

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

• Changed state: Accepted
• Added labels: Type-Enhancement
• Removed labels: Type-Defect

[GoogleCodeExporter]

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

[GoogleCodeExporter]

> 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

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

• Changed state: Fixed

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

• Changed state: Accepted
• Added labels: Milestone-Release0.3.0

[GoogleCodeExporter]

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

• Changed state: WontFix
• Removed labels: Milestone-Release0.3.0