Summary

csc: when .c files are supplied and -c is given, the -o option has no effect

Metadata

Description

as illustrated here,

 $ csc -c hello.scm library.c -o hello.o.myextension

produces hello.o.o, not hello.o.myextension as expected

Changes and comments

[2019-11-12 12:33:44 UTC] sjamaan set difficulty to easy

[2019-11-12 12:33:44 UTC] sjamaan changed component from unknown to compiler

[2019-11-12 12:33:44 UTC] sjamaan changed milestone from someday to 5.2

[2019-11-12 12:33:44 UTC] sjamaan wrote:

Should be relatively easy to fix, nice to get this into 5.2

[2019-11-12 12:53:57 UTC] felix changed status from new to assigned

[2019-11-12 12:53:57 UTC] felix set owner to felix

[2019-11-12 12:53:57 UTC] felix changed component from compiler to core tools

[2019-11-12 17:54:37 UTC] felix wrote:

What is the expected behaviour here? You are passing two files but want to produce one object file, so I assume you want both to be linked together? AFAIK it is not possible to combine multiple .o files in another .o file, unless you produce a library (static or dynamic). `gcc`, for example, produces this, when given multiple files + the `-c` option:

`gcc: cannot specify -o with -c or -S with multiple files`

Perhaps we should produce the same error.

[2019-11-17 13:13:59 UTC] kristianlm wrote:

1573992863759713

[2019-11-17 13:13:59 UTC] kristianlm wrote:

Good point, and thanks for looking into this. I don't know what I want, other than tweetnacl to cross-compile properly. In there, you have:

 klm@kth /tmp ➤ chicken-install -r tweetnacl
 tweetnacl located at /home/klm/.cache/chicken-install/tweetnacl
 klm@kth /tmp ➤ cd /home/klm/.cache/chicken-install/tweetnacl/
 klm@kth ~/.c/c/tweetnacl ➤ cat build-tweetnacl
 #!/bin/sh -e
 "$CHICKEN_CSC" -O2 -d1 -C "$CFLAGS" -L "$LDFLAGS" tweetnacl.impl.c "$@"

When cross compiling this egg, the "$@" contains a -o 'tweetnacl.o.target' so that is where this situation is happening.

Is there now a way to specify C sources in the .egg file? If so, that is probably the correct way to fix this. The only reason Thomas is using a custom build script is to compile the C source file in there.

Otherwise, perhaps a sensible solution is to say that each -o applies to the first source-file preceding it or something like that?

[2019-11-24 03:16:57 UTC] evhan changed status from assigned to closed

[2019-11-24 03:16:57 UTC] evhan set resolution to fixed

[2019-11-24 03:16:57 UTC] evhan wrote:

Fixed by 90b57243, which makes this an error condition with a clear message.

[2019-11-24 12:05:40 UTC] felix changed status from closed to reopened

[2019-11-24 12:05:40 UTC] felix removed resolution fixed

[2019-11-24 12:05:40 UTC] felix wrote:

This breaks in several places where custom-build scripts are used, and probably more. The general problem is that the static compilation uses `-c` and chicken-install passes the additional source dependencies as arguments, which is incorrect.

[2019-11-24 12:06:50 UTC] felix changed difficulty from easy to medium

[2019-11-24 13:45:22 UTC] felix wrote:

To reproduce the error this change triggers, consider the tweetnacl egg: The problem here is that the custom-build script adds an additional file to the csc invocation, taking advantage of the fact that csc will compile all files given on the command line. Previously the "-o" option was partially ignored when multiple files together with the "-c" where given, which seemed to work most of the time, or accidentally met the user's expectations. But strictly speaking, the custom build script is incorrect.

[2019-11-24 15:28:14 UTC] felix wrote:

(ignore my remark about additional dependencies being added - that was a wrong assumption)

[2019-12-01 14:21:52 UTC] kooda wrote:

I think that the patch to error out is right here, and that this method of adding a C file to the custom-build script is wrong.

It only happens to work when building a shared object, but doesn’t work when building a static object (csc is not making an archive file) or when cross-compiling, as Kristian originally reported.

The two proper methods of linking a C library to a Scheme library are: `#include <the_c_file>` inside a `foreign-declare` for example, or using the `c-object` component to build the C library and `objects` component property to link that C library to the Scheme one.

The first method always works, the second requires CHICKEN 5.1.0 or later.

[2019-12-12 16:53:42 UTC] sjamaan wrote:

Fixed with 90b57243dbf25a2b0e32114746d593a8599e1528; but some eggs still need to be fixed

[2019-12-18 13:27:52 UTC] kooda wrote:

Here is a list of eggs that are broken by this change:

- ~~endian-blob~~ (fixed) - ~~random-mtzig~~ (fixed) - ~~rbf~~ (fixed) - sql-de-lite - ~~statistics~~ (fixed in svn) - webview - genann (patch sent) - ~~spiffy-cgi-handlers~~ (fixed) - ~~sqlite3pth~~ (fixed)

[2019-12-18 13:27:52 UTC] kooda wrote:

1576700506962064

[2019-12-18 13:27:52 UTC] kooda wrote:

1576749926936543

[2019-12-18 13:27:52 UTC] kooda wrote:

1576754095744110

[2019-12-18 13:27:52 UTC] kooda wrote:

1576858933384587

[2019-12-18 13:27:52 UTC] kooda wrote:

1577001235753403

[2019-12-18 13:27:52 UTC] kooda wrote:

1577556813694103

[2019-12-28 17:50:01 UTC] andyjpb wrote:

Kooda sent a patch for spiffy-cgi-handlers which I have applied and tagged as 0.7.

[2020-01-16 23:18:31 UTC] zbigniew wrote:

Felix sent me a diabolically clever kludge for sql-de-lite which maintains compatibility with 5.0.0, but I'm wondering if we should just fix it the "right" way (c-object) even though it means a minimum of 5.1.0? Any thoughts?

This assumes the c-object fix works here; I haven't looked at it yet. This build script is terribly complicated and got even more so when modified for Chicken 5.

[2020-01-17 11:03:16 UTC] felix wrote:

I think it is for the egg-author to decide whether breaking compatibility with 5.0.0 is acceptable. I'll provide a c-objects patch, if I can and then we can see what's best.

[2020-02-29 15:09:29 UTC] sjamaan changed status from reopened to closed

[2020-02-29 15:09:29 UTC] sjamaan set resolution to fixed

[2020-02-29 15:09:29 UTC] sjamaan wrote:

Not completely fixed in all eggs yet, but it's not a blocker for the release.