CCF and CFLAGS

[oldk1331]

"./configure -h" mentions CFLAGS, but CFLAGS is not
used in src/lib/Makefile.in, while CCF is used in may
places.

I think we should remove all CCF with CFLAGS, opinions?

[Waldek Hebisch]

I think this is case when old saying "do not fix what is
not broken" applies. 'CFLAGS' in configure is autoconf
idea what things should look like. 'CCF' is what we
currently use. Given that main task of autoconf
is to adapt various setting to hast system one may
believe that autoconf knows better what we should
do. However, in some aspects autoconf has rather
inflexible view how things should be done (for
expample autoconf tries to hide differences between
shared and static libraries while FriCAS needs
specific choice). Historicaly autoconf used to
ship broken setup on some system (specificaly
some aspects of Mac OSX). Build system is has
nasty feature that little can be established
a priori: we need to adapt to specific system with
all its quirks. And the only method to check for
correctness it to try on given system. So debugging
build system is time consuming and needs access to
actual system. In the past FriCAS was build on
many flavous of Linux, Mac OSX, Windows (Cygwin and Mingw),
various BSD variants and Solaris. I would say that this
shows that nothing in FriCAS build system is fundamentaly
broken. Of course, there may be specific problems
due to either changes in FriCAS or involved systems.
Such problems should be fixed. However, lacking
reports of problems the safest way is to keep things
as is.

P.S. I know that FreeBSD folks had problems building FriCAS.
Also there are problem with Mac OSX build and Windows build.
Concerning Cygwin build, AFAIK starting from some time
Cygwin folks ship broken version of clisp -- there is
nothing which we can do to solve this. In the past Martin
Rubey tried ECL for Cygwin build, but apparently ECL on
Cygwin was too buggy. For Mingw + sbcl Gregory Vanuxem
posted some patches and info. In other cases we lack usable
bug reports (and AFAIU cases we we got useful bug reports
are fixed).

--
Waldek Hebisch

[oldk1331]

> I think we should remove all CCF with CFLAGS, opinions?

I revise this a little: we treat CCF as default c flags, but we should
also honor CFLAGS. ($(CC) $(CCF) $(CFLAGS))

On Tue, Feb 21, 2017 at 11:20 PM, Waldek Hebisch
<heb...@math.uni.wroc.pl> wrote:
> I think this is case when old saying "do not fix what is
> not broken" applies. 'CFLAGS' in configure is autoconf
> idea what things should look like. 'CCF' is what we
> currently use. Given that main task of autoconf
> is to adapt various setting to hast system one may
> believe that autoconf knows better what we should
> do. However, in some aspects autoconf has rather
> inflexible view how things should be done (for
> expample autoconf tries to hide differences between
> shared and static libraries while FriCAS needs
> specific choice).

I have a broken case: on a 64bit system to cross compile
a 32bit binary (using 32bit lisp). I have to manually set
CFLAGS to "-m32", because CFLGAS is not used in src/lib.

BTW, can you update config/config.{sub,guess}? Current
configure can't recognize Android system.

[Waldek Hebisch]

I our case cross compilation is a bit more complicated than
usual. First, we have normal C objects and C object to be
used by Lisp. In principle they can differ. One things
is that Closure CL, sbcl and clisp need shared library which
in turn requires position independent code. Ecl uses
use static linking but also prefers position independent code.
gcl uses static linking. Anway, for several lisp implementations
we _must_ generate shared library. There is extra complication
because cmucl only works as 32-bit binary, while normal C
convention on amd64 is to compile C code in 64-bit mode.
In general on 64-bit machines we definitely prefer 64-bit
mode for AXIOMsys. OTOH on machines different than amd64
default mode for C programs frequently is 32-bits. So
in principle we need two sets of flags: general C flags
and flags for use by Lisp. ATM this distinction is only
implemented for cmucl because apparently in other cases
nobody was using other configuration.

For general cross-compilnig we need to build code to run
on build machine to generate various files for target.
So basically we need four sets of C flags: build C,
build Lisp, target C, target Lisp. This can be handled
using two staged build: first normal build for build machine,
than cross build. One should pick all generated files
from native build and use them for cross build.
Another problem is cross compilation of Lisp.
It seem that Closure CL has reasonable support for
cross compilation (but ATM due to bugs on ARM is
probably not good choice). Theoreticaly sbcl
can cross compile, but working out details may
be tricky. For ECL we probably can cheat: capture
generated C and cross compile it for target.

--
Waldek Hebisch

[oldk1331]

> I think this is case when old saying "do not fix what is
> not broken" applies.

OK, another case: I want to have "-O3" optimization or other
debug information. CFLAGS is not used in src/lib/Makefile.in.

About cross-compilnig, it is complicated for FriCAS. I have
an immature idea: to split FriCAS into a C part and pure Lisp
part, the pure Lisp part should be easy to port to other
architecture.

[Waldek Hebisch]

oldk1331 wrote:
>
> BTW, can you update config/config.{sub,guess}? Current
> configure can't recognize Android system.

I have put new config/config.{sub,guess} at

http://www.math.uni.wroc.pl/~hebisch/fricas/config.sub

and

http://www.math.uni.wroc.pl/~hebisch/fricas/config.guess

They are slightly hacked to produce shorter names. Please
test them. If I hear no info about problems I will replace
current config/config.{sub,guess} by the new versions.

--
Waldek Hebisch

[Ralf Hemmecke]

On 03/28/2017 06:39 PM, Waldek Hebisch wrote:
> http://www.math.uni.wroc.pl/~hebisch/fricas/config.sub
>
> and
>
> http://www.math.uni.wroc.pl/~hebisch/fricas/config.guess

> They are slightly hacked to produce shorter names. Please
> test them. If I hear no info about problems I will replace
> current config/config.{sub,guess} by the new versions.

They look pretty much like being generated by/coming from automake.
Why would you expect problems? What exactly did you "hack"?

Ralf

[Waldek Hebisch]

Yes, originals are from autotools. This version is hacked
to produce slightly shorter names, instead of say

x86_64-unknown-linux-gnu

it gives

x86_64-linux-gnu

I do not expect problems. But so I did not expect problems
from older version and Qian says that it has problems on
Android (I would think that it should just use name obtained
for the system and do its tests).

--
Waldek Hebisch

[Ralf Hemmecke]

On 03/29/2017 12:14 AM, Waldek Hebisch wrote:
> Yes, originals are from autotools. This version is hacked
> to produce slightly shorter names, instead of say
>
> x86_64-unknown-linux-gnu
>
> it gives
>
> x86_64-linux-gnu

Oh, I wouldn't change anything that comes from autotools. I'd rather
build on what they provide and let them deal with all the peculiarities
of different systems. What's the real gain of saving a few bytes in such
names? I wouldn't care to invest time in that.

Ralf

[oldk1331]

> I have put new config/config.{sub,guess} at

This compiles fine, but this is from
timestamp='2014-03-23'
why not use latest version?

About 'x86_64-unknown-linux-gnu' vs. 'x86_64-linux-gnu',
I assume the directory structure "target/x86_64-pc-linux-gnu"
is for cross compile purpose, while we currently don't support.
I'm fine with either of the name, but I would against the
changes to config.{sub,guess}, it's better to be done in
configure, to change 'x86_64-unknown-linux-gnu' into
'x86_64-linux-gnu'.