This is the mail archive of the mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: unison-2.10.2-1 and unison-gtk2-2.10.2-1

On Thu, 23 Sep 2004, Andrew Schulman wrote:

> >> > Also, you will probably need to include bits of the ocaml sources in
> >> > your lablgtk2 source package -- do we want to replicate this?
> >>
> >> I'm not sure what you mean.  The user will have to install ocaml
> >> first in order to build from source.  Is anything more required?
> >
> > Is that "ocaml source", or "ocaml binary package"?
> ocaml binary.  All the user needs to build LablGTK is the ocaml
> compiler, plus the contents of /usr/lib/ocaml.  No ocaml source code is
> required.

Great.  Could you please also test it with the shared lib version from

> > The tradition for Cygwin packages is to either have self-contained
> > sources, or to share the sources for some packages (via the
> > "external-source:" directives).  It's unusual for one source package
> > to depend on another.  Although...  The "cygwin" source package
> > depends on the "mingw" and "w32api" sources, so I guess it would be
> > ok.
> So since only ocaml binary is required, and not source, does that
> satisfy your concern?

Yep.  I think I was thrown off by a comment I saw somewhere that bits of
O'Caml source are required.  Since I can't find it now, and can't recall
what it was, the point is probably moot.  Never mind.

> > I think you can't really strip ocaml executables and expect them
> > to work.  Don't strip.
> OK, no problem.  Just trying to follow the packaging instructions...  I
> would add, though, that some OCaml executables can be stripped.  In the
> unison and unison-gtk2 packages, I stripped unison.exe and
> unison-gtk2.exe, and they both work fine.  Is it the difference between
> native and bytecode executables?

Ah, right.  Native executables are regular executables, and thus can be
stripped.  Bytecode executables are basically a bytecode interpreter core
bundled with the actual bytecode to be executed.  The bytecode sometimes
looks like debugging symbols, so strip removes it, with the obvious dire
consequences.  AFAICS, there is no way to distinguish between bytecode and
non-bytecode executables without examining them in a non-trivial way.

For now, I don't strip the O'Caml package at all, which may account for
its 10M size.  Once I debug the shared library build process and make sure
the libraries work correctly, I'll use them to link the executables
instead of the static libs, and the file size should go down.  As time
permits, I'll also try to come up with a more intelligent strip rule than
the current "don't strip anything".
      |\      _,,,---,,_
ZZZzz /,`.-'`'    -.  ;-;;,_
     |,4-  ) )-,_. ,\ (  `'-'		Igor Pechtchanski, Ph.D.
    '---''(_/--'  `-'\_) fL	a.k.a JaguaR-R-R-r-r-r-.-.-.  Meow!

"Happiness lies in being privileged to work hard for long hours in doing
whatever you think is worth doing."  -- Dr. Jubal Harshaw

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]