OCaml and static linking (was old thread: Re: [Fedora-packaging] Issues with Ocaml and Static Linking)

[Toshio Kuratomi]

On Wed, 2007-05-30 at 15:14 +0100, Richard W.M. Jones wrote:
> Toshio Kuratomi wrote:
> > Thanks, those scripts look good.
> 
> So what's the next step?  I've added (or in two cases, changed) 14 OCaml 
> packages which are waiting for another person to review them.  You can 
> get the full list of Bugzillas through this link:
> 
> http://tinyurl.com/2rl4w6
> 
If you,  Gérard, Hans, and the other people working on OCaml think the
guidelines are ready we can discuss and vote to include them at next
week's packaging meeting.  The committee is meeting at Tuesday at 17:00
UTC for about an hour in #fedora-meeting on freenode IRC.  If any of you
can make it to the meeting that would be great as it helps to have
someone familiar with the language there to field any questions that may
come up.

> I understand that everyone's really busy getting F7 out of the door, and 
> also that OCaml doesn't interest many people.  But anyway to kick things 
> off, here are some of the things which I think could be problems:
> 
> (1) Because of the strict dependencies, users could only upgrade ocaml + 
> all OCaml libraries they are using in one go.
> 
> (2) Also as a consequence of (1), if a major release of OCaml comes out, 
> all OCaml libraries have to be upgraded at the same time.  If, for 
> example, we move to 3.10, then all libraries upstream must support 3.10.
> 
>    --> Possible solution to (1) & (2): Put the version number in
>    the library path, as Debian does.  This may allow multiple versions
>    to coexist.
> 
>    --> Upstream support (2) is not much of a problem in reality.
> 
Other packages like this (python, perl, ruby) do have versioned
subdirectories so that might be the best way to go.  Do upstream build
scripts generally make this easy to do?

> (3) OCaml contains a native code compiler, but that compiler hasn't been 
> ported to all architectures that Fedora supports.  It has a bytecode 
> compiler which works everywhere (but is interpreted and hence slow).  I 
> haven't been very careful about detecting if native code is supported on 
> the current architecture.
> 
>    --> ExcludeArch and/or lots of nasty %ifarch sections in %files.
> 
>    --> I don't have a non-native arch to test on.
> 
What's missing?  ppc64?  Is there a possibility of support being added
upstream?  I can't think of any other packages/languages that have this
problem offhand.  We may need to do something nasty with subpackages and
%ifarch but I'd rather avoid that if possible.  I don't know how
possible that is, though.

> (4) rpmlint gives a few familiar warnings:
> 
>    devel-file-in-non-devel-package (about *.cmi files)
> 
>      --> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=241471
> 
Looks like this one is being worked on.

>    only-non-binary-in-usr-lib
> 
>      --> A consequence of the above.
> 
>    unstripped-binary-or-object
> 
>      --> You can't strip OCaml bytecode binaries because the bytecode
>      gets stripped too.  Arguably that's an upstream bug.
> 

>    no-binary
> 
>      --> Packages which contain no binaries should be in noarch -
>      fair enough, but I don't know how to do this in the spec file
>      and keep the subpackages arch-specific.
> 
Yeah -- if one package/subpackage is arch specific then all of the
pieces built from it have to be.

>    configure-without-libdir-spec
> 
>      --> The ./configure scripts are often written in OCaml and don't
>      use the standard autoconf options.
> 
Okay.  So this looks like rpmlint sees ./configure as an autoconf
configure script when it really is not.

> (5) How does the Fedora build system work?  To build a library you need 
> to have the OCaml compiler and all dependent libraries installed 
> (enforced through BuildRequires) and you'll get out an RPM which only 
> installs with the precise compiler and library which were installed when 
> it was compiled.  So the only sequence that works is:
>    # remove all ocaml RPMs
>    $ rpmbuild -ba ocaml.spec
>    # install ocaml RPM
>    $ rpmbuild -ba ocaml-lib1.spec
>    # install ocaml lib1 RPM
>    $ rpmbuild -ba ocaml-lib2.spec
>    # install ocaml lib2 RPM
>    etc.
> 
Every build is a fresh mock buildroot.  It includes the packages in the
minimal install plus BuildRequires and their dependencies.  The packages
are drawn from the current download repository plus the packages that
have been built recently but not yet made it to the repository.  With
the new koji builders (for F7) you have to tell it to do a chainbuild to
guarantee that the recently built package is included in the new build.
Until a better UI is worked out, here's a post on how to do that:

http://www.redhat.com/archives/fedora-devel-list/2007-May/msg01850.html

I think that will take care of getting new versions of OCaml through the
build system.

-Toshio
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-packaging/attachments/20070530/fab86fd2/attachment.sig>