[Bug 194011] Review Request: curry - Münster Curry compiler

bugzilla at redhat.com bugzilla at redhat.com
Fri Jun 9 00:54:51 UTC 2006


Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug report.

Summary: Review Request: curry -  Münster Curry compiler


https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=194011





------- Additional Comments From tibbs at math.uh.edu  2006-06-08 20:46 EST -------
I've been thinking about this a bit and took a look at a couple of things.

Obviously the best possible solution would be for the curry compiler to
dynamically link the executables it creates, and then package the runtime
separately.  The question is, how feasible is this?  I don't think anything
prevents the runtime from being made into a .so; it would just be a few lines in
runtime/Makefile.in.  And the curry compiler (cyc) is really just a shell script
that turns the curry source into C, then calls GCC to compile it and then links it:

$exec $CC $debug $ccopts $ldopts /tmp/cyc$$.c $linkfiles $libs $dbglib -lcurry
@LDFLAGS@ @LIBS@

So it may be possible to actually make things work without an insane amount of
effort.

However, assuming that we can't achieve curry packaging Nirvana, is the current
package behavior acceptable?   Obviously we dislike static libraries and static
linking, but if there's no other way to make it work then we either have to
package the compiler as is or not package it at all.  The standard argument
against static linking is one of security: you have to fix every package that
linked in the bad library individually.  The curry compiler is mostly of
research interest and isn't going to be used to produce a large number of
security-sensitive programs, so it's probably reasonable to discount the
security argument.

What remains is Ralf's comment about splitting out the _g library.  It is large
and not a terrible idea, but there's the issue of cymake failing.  However,
cymake is just a shell script which calls cyc; it should be easy to patch the
appropriate one to check for the existence of the debug library and simply bail
with a useful error if it doesn't exist.

So the real issue is how much work is involved to make things a bit cleaner. 
What do you think?

-- 
Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug, or are watching the QA contact.




More information about the Fedora-package-review mailing list