Bug 169704 - Review Request: mosml - Moscow ML
Summary: Review Request: mosml - Moscow ML
Keywords:
Status: CLOSED NEXTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: Package Review
Version: rawhide
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: John Mahowald
QA Contact: Fedora Package Reviews List
URL: http://math.ifi.unizh.ch/fedora/4/i38...
Whiteboard:
Depends On:
Blocks: FE-ACCEPT
TreeView+ depends on / blocked
 
Reported: 2005-10-01 17:03 UTC by Gérard Milmeister
Modified: 2007-11-30 22:11 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2007-02-20 19:41:57 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
Build log (29.91 KB, text/plain)
2006-08-21 15:59 UTC, John Mahowald
no flags Details
mail from upstream (1.62 KB, text/plain)
2006-08-24 17:05 UTC, Gérard Milmeister
no flags Details

Description Gérard Milmeister 2005-10-01 17:03:15 UTC
Spec: http://math.ifi.unizh.ch/fedora/spec/mosml.spec
SRPM: http://math.ifi.unizh.ch/fedora/4/i386/SRPMS.gemi/mosml-2.01-3.src.rpm
Description:
Moscow ML provides a light-weight implementation of full Standard ML,
including Modules and some extensions.  Standard ML is a strict
functional language widely used in teaching and research.

Comment 1 John Mahowald 2005-11-20 20:25:41 UTC
SRPM is 404 not found.

Comment 2 Gérard Milmeister 2005-11-20 20:57:25 UTC
This should be:
http://math.ifi.unizh.ch/fedora/4/i386/SRPMS.gemi/mosml-2.01-4.src.rpm

Comment 3 John Mahowald 2005-12-20 22:10:42 UTC
Missing BuildRequires: gd-devel

A few quick things rpmlint noticed after it did build with gd-devel:

* rpmlint of mosml: Missing changelog. Why aren't the headers and devel files in
a devel subpackage, are they required for using the program?
* rpmlint of mosml-examples: No need for any win32 Makefile stuff.


Comment 4 Gérard Milmeister 2006-01-02 23:43:32 UTC
Items fixed.

http://math.ifi.unizh.ch/fedora/4/i386/SRPMS.gemi/mosml-2.01-5.src.rpm



Comment 5 John Mahowald 2006-02-27 15:38:46 UTC
The CAML light part of the license says "The user undertakes not to carry out
any paying distribution of the software." while allowing for cost of
reproduction. Don't know if this non commercial clause is too restrictive.

The .sos do not seem to have any versioning, mosml does this a different wa?

rpmlint complains about several shlib-with-non-pic-code and linking problems
like the following example:

E: mosml-pg shlib-with-non-pic-code /usr/lib/mosml/lib/libmpq.so
The listed shared libraries contain object code that was compiled
without -fPIC. All object code in shared libraries should be
recompiled separately from the static libraries with the -fPIC option.

Another common mistake that causes this problem is linking with
``gcc -Wl,-shared'' instead of ``gcc -shared''.

E: mosml-pg library-not-linked-against-libc /usr/lib/mosml/lib/libmpq.so


Comment 6 Gérard Milmeister 2006-03-06 23:55:35 UTC
(In reply to comment #5)
> The CAML light part of the license says "The user undertakes not to carry out
> any paying distribution of the software." while allowing for cost of
> reproduction. Don't know if this non commercial clause is too restrictive.
It seems that CAML light has been relicensed to QPL and LGPL:
http://caml.inria.fr/caml-light/license.en.html
Would that solve the licensing problem?

Comment 7 Gérard Milmeister 2006-03-06 23:57:17 UTC
(In reply to comment #5)
> The CAML light part of the license says "The user undertakes not to carry out
> any paying distribution of the software." while allowing for cost of
> reproduction. Don't know if this non commercial clause is too restrictive.
It seems that CAML light has been relicensed to QPL and LGPL:
http://caml.inria.fr/caml-light/license.en.html
Would that solve the licensing problem?

Comment 8 John Mahowald 2006-04-08 15:34:25 UTC
That site does not seem to be up now for some reason.

However, QPL and LGPL are both OSI approved, a good sign.
http://www.opensource.org/licenses/

It would be best to check the actual text though.

Comment 9 Gérard Milmeister 2006-04-09 10:26:57 UTC
The site is up again now.

Comment 10 John Mahowald 2006-04-25 04:43:45 UTC
Not building on devel x86_64:

+ cd dynlibs
+ make MOSMLHOME=/var/tmp/mosml-2.01-5-root-mockbuild/usr/lib64/mosml
cd intinf; make
make[1]: Entering directory `/builddir/build/BUILD/mosml/src/dynlibs/intinf'
gcc -Dunix -O2 -fno-defer-pop 
-I/var/tmp/mosml-2.01-5-root-mockbuild/usr/lib64/mosml/include  -c -o intinf.o
intinf.c
intinf.c: In function 'largeint_get_str':
intinf.c:319: warning: incompatible implicit declaration of built-in function
'malloc'
ld -shared -o libmgmp.so intinf.o /usr/lib/libgmp.a
ld: intinf.o: relocation R_X86_64_32 against `first_atoms' can not be used when
making a shared object; recompile with -fPIC
intinf.o: could not read symbols: Bad value
make[1]: *** [libmgmp.so] Error 1


Comment 11 Gérard Milmeister 2006-04-25 21:30:46 UTC
Could you try this:
http://math.ifi.unizh.ch/fedora/5/i386/SRPMS.gemi/mosml-2.01-7.fc5.src.rpm

If it doesn't work, we need to get an expert on x86_64 compiling and linking.

Comment 12 John Mahowald 2006-04-30 21:24:26 UTC
Nope.

ld -shared -o libmgmp.so intinf.o /usr/lib/libgmp.so
ld: /usr/lib/libgmp.so: No such file: No such file or directory


Comment 13 Gérard Milmeister 2006-05-05 13:59:52 UTC
Next try:
http://math.ifi.unizh.ch/fedora/5/i386/SRPMS.gemi/mosml-2.01-8.fc5.src.rpm

Comment 14 John Mahowald 2006-07-28 04:31:16 UTC
Been a while, sorry about that.

Builds on x86_64!

But rpmlint doesn't link the lack of a soname version:

E: mosml invalid-soname /usr/lib64/mosml/lib/libmregex.so libmregex.so
E: mosml invalid-soname /usr/lib64/mosml/lib/libmunix.so libmunix.so
E: mosml invalid-soname /usr/lib64/mosml/lib/libmgmp.so libmgmp.so

And symlinks are broken, looks like lib64 problems.

W: mosml dangling-relative-symlink /usr/bin/mosmlyac ../lib/mosml/bin/mosmlyac
W: mosml dangling-relative-symlink /usr/bin/mosmllex ../lib/mosml/bin/mosmllex
W: mosml dangling-relative-symlink /usr/bin/camlrunm ../lib/mosml/bin/camlrunm
W: mosml dangling-relative-symlink /usr/bin/mosmlc ../lib/mosml/bin/mosmlc
W: mosml dangling-relative-symlink /usr/bin/mosml ../lib/mosml/bin/mosml


Comment 15 Gérard Milmeister 2006-07-28 18:10:41 UTC
For the links I use %{_lib} now. This should take care of that issue:
http://math.ifi.unizh.ch/fedora/5/i386/SRPMS.gemi/mosml-2.01-9.src.rpm

I don't think there is anything to done about the soname problem.
The classification of this problem as an error is wrong IMHO.
There are many packages that use plugin type .so files with either
no soname or an unversioned one, like here (see for example gaim
or many python packages).

Comment 16 John Mahowald 2006-08-21 15:58:02 UTC
Doesn't build on x86_64 devel, however, something about 

*** glibc detected *** ../camlrunm: munmap_chunk(): invalid pointer:
0x0000000000633000 ***


Comment 17 John Mahowald 2006-08-21 15:59:46 UTC
Created attachment 134570 [details]
Build log

Comment 18 Gérard Milmeister 2006-08-21 18:17:19 UTC
This is bad. The error appears probably due to new checks
in glibc and I guess that on i386 this will also happen.
Could you try in a i386 build environment?
I mailed upstream about this.

Comment 19 Gérard Milmeister 2006-08-24 17:05:05 UTC
Created attachment 134834 [details]
mail from upstream

Here is the answer from Peter Sestoft. Since I don't have
access to x86_64, could you look at the points raised?

Comment 20 Gérard Milmeister 2006-08-24 18:52:27 UTC
I managed to build in mock on fedora-development-i386-core
flawlessly without the problem you had. So this seems
very much related to x86_64.

Comment 21 John Mahowald 2006-10-04 05:25:23 UTC
Just recently rebuilt this on devel x86_64, and still fails at the same spot.
The very same invalid pointer, even.

However, the Array.sml that referenced is not empty.

The preprocessor referenced is /lib/cpp, which I believe is correct.

Comment 22 John Mahowald 2006-10-14 16:22:17 UTC
Built on same machine for devel i386. Perhaps this could be ExcludeArch x86_64?

Comment 23 Gérard Milmeister 2006-10-14 16:39:30 UTC
(In reply to comment #22)
> Perhaps this could be ExcludeArch x86_64?
It's ok for me.
It is possible for Fedora x64_64 to use i386 repositories, isn't it?



Comment 24 Gérard Milmeister 2007-02-11 17:10:24 UTC
May we proceed with the review and exclude x86_64?

Comment 25 John Mahowald 2007-02-16 08:24:59 UTC
FYI the mosml site seems to have a contributed rpm.

Does not build on x86_64. Add to the x86_64 exclude tracker.

2.01-9 again, this time builds on F7 devel i386:

rpmlint of mosml-devel-2.01-9.fc7.i386.rpm:W: mosml-devel invalid-license
GPL/ATT/INRIA/Distributable
W: mosml-devel no-documentation

rpmlint of mosml-pg-2.01-9.fc7.i386.rpm:W: mosml-pg invalid-license
GPL/ATT/INRIA/Distributable
E: mosml-pg invalid-soname /usr/lib/mosml/lib/libmpq.so libmpq.so
W: mosml-pg no-documentation

rpmlint of mosml-gd-2.01-9.fc7.i386.rpm:W: mosml-gd invalid-license
GPL/ATT/INRIA/Distributable
E: mosml-gd invalid-soname /usr/lib/mosml/lib/libmgd.so libmgd.so
W: mosml-gd no-documentation

rpmlint of mosml-2.01-9.fc7.i386.rpm:W: mosml invalid-license
GPL/ATT/INRIA/Distributable
E: mosml invalid-soname /usr/lib/mosml/lib/libmregex.so libmregex.so
E: mosml invalid-soname /usr/lib/mosml/lib/libmunix.so libmunix.so
E: mosml invalid-soname /usr/lib/mosml/lib/libmgmp.so libmgmp.so

rpmlint of mosml-gdbm-2.01-9.fc7.i386.rpm:W: mosml-gdbm invalid-license
GPL/ATT/INRIA/Distributable
E: mosml-gdbm invalid-soname /usr/lib/mosml/lib/libmgdbm.so libmgdbm.so
W: mosml-gdbm no-documentation

rpmlint of mosml-docs-2.01-9.fc7.i386.rpm:W: mosml-docs invalid-license
GPL/ATT/INRIA/Distributable

rpmlint of mosml-examples-2.01-9.fc7.i386.rpm:W: mosml-examples invalid-license
GPL/ATT/INRIA/Distributable


no-documentation ignore, docs subpackage

Good:
+ Proper BuildRoot
+ Macros throughout
+ subpackages require base package
+ commented
+ defattr for all packages
+ ownership good
+ header files split out
+ Downloaded source matches

APPROVED

Comment 26 Gérard Milmeister 2007-02-20 19:41:57 UTC
Build on devel and FC6 for i386 and ppc.
Added to FE-ExcludeArch-x64 tracker.
I did not try to build it on x86_64.


Note You need to log in before you can comment on or make changes to this bug.