> If you use either gcc or clang, you can export $CC before make.

Taking `build_libj.sh` for example, the problem is that it only detects gcc in
cases where CC contains "gcc" as a substring. This breaks when, for example,
CC=cc and cc is a symlink to some gcc. For example, when building for a
non-native target, one usually sets up cc to point to the appropriate build
toolchain, e.g. /usr/bin/arm-linux-gnueabihf-gcc.

Interestingly, `build_jconsole.sh` adopts a diffrent, stronger assumption that
CC=gcc when gcc is the compiler. Note that clang compilation mostly Just Works
TM, since the scripts assume clang by default.

> j forum discards attachment so we can't see your patch.

Oops. Thank you for pointing this out. Including both patches in the body is
probably too much clutter, so for illustrative purposes, I will simply post the
smaller one below:


--- make/build_jconsole.sh      2019-12-17 18:25:11.713700768 +0900
+++ make/build_jconsole.sh      2019-12-17 18:26:45.090341029 +0900
@@ -5,6 +5,7 @@
 cd ~
 
 macmin="-mmacosx-version-min=10.6"
+ccver=$(${CC} --version)
 USE_LINENOISE="${USE_LINENOISE:=1}"
 
 if [ "x$CC" = x'' ] ; then
@@ -20,7 +21,7 @@
 export CC
 fi
 
-if [ $CC = "gcc" ] ; then
+if [ -z "${ccver##*(GCC)*}" ]; then
 # gcc
 common=" -fPIC -O1 -fwrapv -fno-strict-aliasing -Wextra 
-Wno-maybe-uninitialized -Wno-unused-parameter -Wno-sign-compare -Wno-clobbered 
-Wno-empty-body -Wno-unused-value -Wno-pointer-sign -Wno-parentheses"
 OVER_GCC_VER6=$(echo `$CC -dumpversion | cut -f1 -d.` \>= 6 | bc)


Using the above, and a similar one for `build_libj.sh`, I have successfully
compiled for aarch64 and x86 musl-based toolchains.

bill lam <[email protected]> wrote:

> j forum discards attachment so we can't see your patch.
>
> If you use either gcc or clang, you can export $CC before make.
>
> FWIW, I have no problem in cross compiling Windows binary with mingw on
> linux using make2.
>
> On Tue, Jan 21, 2020, 10:36 AM ethiejiesa via Source <[email protected]>
> wrote:
>
> > Hello Source,
> >
> > Support for cross-compilation is broken by assumptions made in
> > `make/build_jconsole.sh` and `make/build_libj.sh`. Is there a reasonable
> > fix?
> > I attach some naïve patches that work for my personal (linux) use case.
> >
> > I am the maintainer of the J package for Void Linux. The distribution
> > offers
> > binary package downloads for several target platforms by cross-compiling
> > packages on a build farm. In order to support their build toolchains, I
> > have to
> > patch `make/build_{jconsole,libj}.sh`.
> >
> > In particular, the problem is that the scripts attempt *ad hoc* detection
> > of
> > gcc via path parsing, and cross-compilation toolchains break those
> > assumptions.
> > This can be worked around by instead parsing the output of `$CC --version`.
> > Please see the attached patches against J901-d for a concrete example.
> >
> > On a larger note, however, the above fix is still a fragile hack. Ideally,
> > we
> > want to be completely compiler agnostic without directly checking compiler
> > and
> > version information. The current state of affairs seems to be simply
> > setting
> > compiler flags (for reasons I do not grok yet); however, perhaps we could
> > move
> > the necessary flags into equivalent `#pragma` statements or something
> > similar?
> >
> > I am out of my depth here, so I mostly intend this email as a mean of
> > instigating discussion.
> >
> > Cheers,
> > BW
> > ----------------------------------------------------------------------
> > For information about J forums see http://www.jsoftware.com/forums.htm
> >
> ----------------------------------------------------------------------
> For information about J forums see http://www.jsoftware.com/forums.htm
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm

Reply via email to