[Aldor-l] Distributing Aldor
Bill Page
bill.page at newsynthesis.org
Wed Sep 10 12:10:08 EDT 2008
2008/9/10 <pip88nl at gmail.com>:
>
> it is great that you are trying to build Aldor. For reasons of
> convenience, I put all configure-yielded values into a single file,
> config.mk. If you look at that, you will find a "Toolchain" section where
> it shows the found archiver, assembler, compilers, etc. Can you show me
> that section?
#################
### Toolchain ###
#################
AR = ar
AS = as
CC = gcc
CXX = g++
CPP = gcc -E
RANLIB = ranlib
HAR = /usr/ccs/bin/ar
HAS = /usr/ccs/bin/as
HCC = /opt/SUNWspro/bin/cc
HCXX = /opt/csw/gcc4/bin/c++
HRANLIB = /usr/ccs/bin/ranlib
DLLEXT = .so
LIBEXT = a
EXEEXT =
XCOMP = no
SHLIBS = yes
################
> Also, there might be a problem with the cross compilation
> support, which I added recently. There are HAR, HCC, etc. variables
> showing the "host compiler". There could be a problem with this
> which I will eliminate now.
You are right, these results seem strange to me:
-bash-3.00$ which ar
/usr/ccs/bin/ar
-bash-3.00$ ar -V
ar: Software Generation Utilities (SGU) Solaris-ELF (4.0)
-bash-3.00$ which as
/usr/ccs/bin/as
-bash-3.00$ as -V
as: Sun Compiler Common 10 Patch 09/20/2005
-bash-3.00$ which cc
/opt/SUNWspro/bin/cc
-bash-3.00$ cc -V
cc: Sun C 5.8 2005/10/13
These are the native Sun tools - not the tools that I was expecting
the build to use. It was my intention to use only the GNU/Blastwave
toolset. For example:
-bash-3.00$ which gcc
/opt/csw/gcc4/bin/gcc
-bash-3.00$ gcc --version
gcc (GCC) 4.0.2
So I think I might have a problem with the PATH:
-bash-3.00$ echo $PATH
/opt/csw/bin:/usr/sbin:/usr/bin:/usr/dt/bin:/usr/openwin/bin:/usr/ccs/bin::/usr/local/bin:/opt/csw/i386-pc-solaris2.8/bin:/opt/SUNWspro/bin:/usr/sfw/bin:/usr/ucb:/etc:.
-bash-3.00$ export PATH=/opt/csw/i386-pc-solaris2.8/bin:/opt/csw/gcc4/bin:$PATH
Now I get
-bash-3.00$ which ar
/opt/csw/i386-pc-solaris2.8/bin/ar
-bash-3.00$ ar --version
GNU ar 2.17
etc.
> If you could download a new tarball, this contains the fix for
> this possible issue.
>
Ok, I will do that. See below.
> Also, could you do the following in a directory not containing any
> Makefiles:
>
> make -p | grep LINK
>
-bash-3.00$ make -p | grep LINK
make: *** No targets specified and no makefile found. Stop.
LINK.o = $(CC) $(LDFLAGS) $(TARGET_ARCH)
LINK.p = $(PC) $(PFLAGS) $(CPPFLAGS) $(LDFLAGS) $(TARGET_ARCH)
LINK.cc = $(CXX) $(CXXFLAGS) $(CPPFLAGS) $(LDFLAGS) $(TARGET_ARCH)
LINK.r = $(FC) $(FFLAGS) $(RFLAGS) $(LDFLAGS) $(TARGET_ARCH)
LINK.C = $(LINK.cc)
LINK.S = $(CC) $(ASFLAGS) $(CPPFLAGS) $(LDFLAGS) $(TARGET_MACH)
LINK.c = $(CC) $(CFLAGS) $(CPPFLAGS) $(LDFLAGS) $(TARGET_ARCH)
LINK.s = $(CC) $(ASFLAGS) $(LDFLAGS) $(TARGET_MACH)
LINK.cpp = $(LINK.cc)
LINK.F = $(FC) $(FFLAGS) $(CPPFLAGS) $(LDFLAGS) $(TARGET_ARCH)
LINK.f = $(FC) $(FFLAGS) $(LDFLAGS) $(TARGET_ARCH)
$(LINK.o) $^ $(LOADLIBES) $(LDLIBS) -o $@
$(LINK.c) $^ $(LOADLIBES) $(LDLIBS) -o $@
$(LINK.cc) $^ $(LOADLIBES) $(LDLIBS) -o $@
$(LINK.C) $^ $(LOADLIBES) $(LDLIBS) -o $@
$(LINK.cpp) $^ $(LOADLIBES) $(LDLIBS) -o $@
$(LINK.p) $^ $(LOADLIBES) $(LDLIBS) -o $@
$(LINK.f) $^ $(LOADLIBES) $(LDLIBS) -o $@
$(LINK.F) $^ $(LOADLIBES) $(LDLIBS) -o $@
$(LINK.r) $^ $(LOADLIBES) $(LDLIBS) -o $@
$(LINK.s) $^ $(LOADLIBES) $(LDLIBS) -o $@
$(LINK.S) $^ $(LOADLIBES) $(LDLIBS) -o $@
$(LINK.o) $^ $(LOADLIBES) $(LDLIBS) -o $@
$(LINK.p) $^ $(LOADLIBES) $(LDLIBS) -o $@
$(LINK.cc) $^ $(LOADLIBES) $(LDLIBS) -o $@
$(LINK.r) $^ $(LOADLIBES) $(LDLIBS) -o $@
$(LINK.C) $^ $(LOADLIBES) $(LDLIBS) -o $@
$(LINK.S) $^ $(LOADLIBES) $(LDLIBS) -o $@
$(LINK.c) $^ $(LOADLIBES) $(LDLIBS) -o $@
$(LINK.s) $^ $(LOADLIBES) $(LDLIBS) -o $@
$(LINK.cpp) $^ $(LOADLIBES) $(LDLIBS) -o $@
$(LINK.F) $^ $(LOADLIBES) $(LDLIBS) -o $@
$(LINK.f) $^ $(LOADLIBES) $(LDLIBS) -o $@
-bash-3.00$
> I am using that standard rule from GNU make, which usually just calls
> gcc, but it might call ld directly. This command shows me
>
> LINK.o = $(CC) $(LDFLAGS) $(TARGET_ARCH)
>
> among others. If it show you the same, there might be some problem
> with your C compiler finding the wrong ld or there might be problems
> with LDFLAGS.
It seems to be the same.
LDFLAGS is not set before running ./configure
-bash-3.00$ echo $LDFLAGS
In config.mk, you will also see the line
>
> .SILENT:
>
> at the beginning. Please comment that out and try the build again.
First download new tarball:
-bash-3.00$ rm -rf aldor-1.1*
-bash-3.00$ wget http://xinutec.org/~pippijn/en/aldor-1.1.0-1_agpl.tar.gz
-bash-3.00$ wget http://xinutec.org/~pippijn/en/aldor-1.1.0-1_apl.tar.gz
-bash-3.00$ gunzip -c aldor-1.1.0-1_agpl.tar.gz | tar x
-bash-3.00$ gunzip -c aldor-1.1.0-1_apl.tar.gz | tar x
-bash-3.00$ cd aldor-1.1.0-1
Start new build:
-bash-3.00$ ./configure --prefix=$HOME/aldor
Check and modify config.mk:
-bash-3.00$ vi config.mk
## .SILENT:
PACKAGE = aldor
...
#################
### Toolchain ###
#################
AR = ar
AS = as
CC = gcc
CXX = g++
CPP = gcc -E
RANLIB = ranlib
HAR = /opt/csw/i386-pc-solaris2.8/bin/ar
HAS = /opt/csw/i386-pc-solaris2.8/bin/as
HCC = /opt/SUNWspro/bin/cc
HCXX = /opt/csw/gcc4/bin/c++
HRANLIB = /opt/csw/i386-pc-solaris2.8/bin/ranlib
DLLEXT = .so
LIBEXT = a
EXEEXT =
XCOMP = no
SHLIBS = yes
################
Now the only one that looks a little odd is HCC, but maybe this is
correct. I presume the HCC will not actually be used here, right?
-bash-3.00$ which cc
/opt/SUNWspro/bin/cc
-bash-3.00$ /opt/SUNWspro/bin/cc -V
cc: Sun C 5.8 2005/10/13
---
-bash-3.00$ source setenv.sh
-bash-3.00$ make prepare 2>&1 | tee build.log
Oops, I see
/opt/SUNWspro/bin/cc -g -O2 -O0 -g3 -ggdb3
in the build.log! Since CC = gcc Why is is using this compiler? Maybe
I need to set
-bash-3.00$ export CC=gcc
No, that didn't work. Let's try making a symlink to gcc for cc in
/opt/csw/i386-pc-solaris2.8/bin
-bash-3.00$ ln -s /opt/csw/gcc4/bin/gcc cc
Now I get
-bash-3.00$ which cc
/opt/csw/i386-pc-solaris2.8/bin/cc
-bash-3.00$ cc --version
cc (GCC) 4.0.2
Better?
-bash-3.00$ make clean
-bash-3.00$ ./configure --prefix=$HOME/aldor
-bash-3.00$ vi config.mk
And in config.mk I see:
HAR = /opt/csw/i386-pc-solaris2.8/bin/ar
HAS = /opt/csw/i386-pc-solaris2.8/bin/as
HCC = /opt/csw/i386-pc-solaris2.8/bin/cc
HCXX = /opt/csw/gcc4/bin/c++
HRANLIB = /opt/csw/i386-pc-solaris2.8/bin/ranlib
Now the first set of make completes without error:
-bash-3.00$ source setenv.sh
-bash-3.00$ make prepare 2>&1 | tee build.log
But during the next step:
-bash-3.00$ make compiler 2>&1 | tee -a build.log
We stop here (I am running with ## .SILENT):
----
...
CC /export/home0/wspage/aldor-1.1.0-1/src/compiler/port/opsys.s
gcc -g -O2 -O0 -g3 -ggdb3 -fPIC -DPIC -shared -D_GLIBCXX_DEBUG
-D_GLIBCXX_DEBUG_PEDANTIC -D_GLIBCXX_CONCEPT_CHECKS
-I/export/home0/wspage/aldor-1.1.0-1/extra/rona/include -Iinclude
-I/export/home0/wspage/aldor-1.1.0-1/include -DIN_PORT -DIN_GENERAL
-DIN_STRUCT -DIN_PHASES -DIN_TOPLEVEL -c -S
/export/home0/wspage/aldor-1.1.0-1/src/compiler/port/opsys.c -o
/export/home0/wspage/aldor-1.1.0-1/src/compiler/port/opsys.s || \
( echo ""Error executing command:" gcc -c \$CFLAGS opsys.c
-o opsys.s" && echo "CFLAGS = -g -O2 -O0 -g3 -ggdb3 -fPIC -DPIC
-shared -D_GLIBCXX_DEBUG -D_GLIBCXX_DEBUG_PEDANTIC
-D_GLIBCXX_CONCEPT_CHECKS
-I/export/home0/wspage/aldor-1.1.0-1/extra/rona/include -Iinclude
-I/export/home0/wspage/aldor-1.1.0-1/include -DIN_PORT -DIN_GENERAL
-DIN_STRUCT -DIN_PHASES -DIN_TOPLEVEL " && exit 1)
/export/home0/wspage/aldor-1.1.0-1/src/compiler/port/opsys.c: In
function 'osFnameIsAbsolute':
/export/home0/wspage/aldor-1.1.0-1/src/compiler/port/opsys.c:350:
error: 'FDIRSEP' undeclared (first use in this function)
/export/home0/wspage/aldor-1.1.0-1/src/compiler/port/opsys.c:350:
error: (Each undeclared identifier is reported only once
/export/home0/wspage/aldor-1.1.0-1/src/compiler/port/opsys.c:350:
error: for each function it appears in.)
/export/home0/wspage/aldor-1.1.0-1/src/compiler/port/opsys.c:352:
error: 'FDIRSEPALT' undeclared (first use in this function)
/export/home0/wspage/aldor-1.1.0-1/src/compiler/port/opsys.c:354:
error: 'FDEVSEP' undeclared (first use in this function)
/export/home0/wspage/aldor-1.1.0-1/src/compiler/port/opsys.c: In
function 'osFnameParse':
/export/home0/wspage/aldor-1.1.0-1/src/compiler/port/opsys.c:372:
error: 'FDEVSEP' undeclared (first use in this function)
/export/home0/wspage/aldor-1.1.0-1/src/compiler/port/opsys.c:372:
error: 'FDIRSEP' undeclared (first use in this function)
/export/home0/wspage/aldor-1.1.0-1/src/compiler/port/opsys.c:372:
error: 'FDIRSEPALT' undeclared (first use in this function)
/export/home0/wspage/aldor-1.1.0-1/src/compiler/port/opsys.c:379:
error: 'FTYPESEP' undeclared (first use in this function)
/export/home0/wspage/aldor-1.1.0-1/src/compiler/port/opsys.c: In
function 'osFnameUnparse':
/export/home0/wspage/aldor-1.1.0-1/src/compiler/port/opsys.c:452:
error: 'FDEVSEP' undeclared (first use in this function)
/export/home0/wspage/aldor-1.1.0-1/src/compiler/port/opsys.c:452:
error: 'FDIRSEP' undeclared (first use in this function)
/export/home0/wspage/aldor-1.1.0-1/src/compiler/port/opsys.c:452:
error: 'FDIRSEPALT' undeclared (first use in this function)
/export/home0/wspage/aldor-1.1.0-1/src/compiler/port/opsys.c:461:
error: 'FTYPESEP' undeclared (first use in this function)
/export/home0/wspage/aldor-1.1.0-1/src/compiler/port/opsys.c: In
function 'osSubdir':
/export/home0/wspage/aldor-1.1.0-1/src/compiler/port/opsys.c:502:
error: 'FDEVSEP' undeclared (first use in this function)
/export/home0/wspage/aldor-1.1.0-1/src/compiler/port/opsys.c:502:
error: 'FDIRSEP' undeclared (first use in this function)
/export/home0/wspage/aldor-1.1.0-1/src/compiler/port/opsys.c:502:
error: 'FDIRSEPALT' undeclared (first use in this function)
/export/home0/wspage/aldor-1.1.0-1/src/compiler/port/opsys.c: In
function 'osFnameDirEqual':
/export/home0/wspage/aldor-1.1.0-1/src/compiler/port/opsys.c:531:
error: 'FCURDIR' undeclared (first use in this function)
/export/home0/wspage/aldor-1.1.0-1/src/compiler/port/opsys.c:535:
error: 'FDIRSEP' undeclared (first use in this function)
/export/home0/wspage/aldor-1.1.0-1/src/compiler/port/opsys.c:535:
error: 'FDIRSEPALT' undeclared (first use in this function)
/export/home0/wspage/aldor-1.1.0-1/src/compiler/port/opsys.c: In
function 'osPathLength':
/export/home0/wspage/aldor-1.1.0-1/src/compiler/port/opsys.c:638:
error: 'FPATHSEP' undeclared (first use in this function)
/export/home0/wspage/aldor-1.1.0-1/src/compiler/port/opsys.c: In
function 'osPathParse':
/export/home0/wspage/aldor-1.1.0-1/src/compiler/port/opsys.c:651:
error: 'FPATHSEP' undeclared (first use in this function)
/export/home0/wspage/aldor-1.1.0-1/src/compiler/port/opsys.c: At top level:
/export/home0/wspage/aldor-1.1.0-1/src/compiler/port/opsys.c:1005:
error: conflicting types for 'osMemMap'
/export/home0/wspage/aldor-1.1.0-1/include/opsys.h:360: error:
previous declaration of 'osMemMap' was here
Error executing command: gcc -c $CFLAGS opsys.c -o opsys.s
CFLAGS = -g -O2 -O0 -g3 -ggdb3 -fPIC -DPIC -shared
-D_GLIBCXX_DEBUG -D_GLIBCXX_DEBUG_PEDANTIC -D_GLIBCXX_CONCEPT_CHECKS
-I/export/home0/wspage/aldor-1.1.0-1/extra/rona/include -Iinclude
-I/export/home0/wspage/aldor-1.1.0-1/include -DIN_PORT -DIN_GENERAL
-DIN_STRUCT -DIN_PHASES -DIN_TOPLEVEL
make[3]: *** [/export/home0/wspage/aldor-1.1.0-1/src/compiler/port/opsys.s]
Error 1
rm /export/home0/wspage/aldor-1.1.0-1/src/compiler/port/cport_t.s
/export/home0/wspage/aldor-1.1.0-1/src/compiler/port/cport.s
make[3]: Leaving directory
`/export/home0/wspage/aldor-1.1.0-1/src/compiler/port'
make[2]: *** [port.build.tag] Error 1
make[2]: Leaving directory `/export/home0/wspage/aldor-1.1.0-1/src/compiler'
make[1]: *** [build] Error 1
make[1]: Leaving directory `/export/home0/wspage/aldor-1.1.0-1/src/compiler'
make[1]: Entering directory `/export/home0/wspage/aldor-1.1.0-1/src/frontend'
for i in ; do \
make -w --no-builtin-rules $i.build.tag || exit 1; \
done
gcc -g -O2 -O0 -g3 -ggdb3 -D_GLIBCXX_DEBUG -D_GLIBCXX_DEBUG_PEDANTIC
-D_GLIBCXX_CONCEPT_CHECKS
-I/export/home0/wspage/aldor-1.1.0-1/extra/rona/include -Iinclude
-I/export/home0/wspage/aldor-1.1.0-1/include -c -o
/export/home0/wspage/aldor-1.1.0-1/src/frontend/aldor.o
/export/home0/wspage/aldor-1.1.0-1/src/frontend/aldor.c
printf "%10s %-20s\n" "LD" /export/home0/wspage/aldor-1.1.0-1/obj/bin/aldor
LD /export/home0/wspage/aldor-1.1.0-1/obj/bin/aldor
/export/home0/wspage/aldor-1.1.0-1/autoconf/install-sh -c -d
/export/home0/wspage/aldor-1.1.0-1/obj/bin/
g++ -g -O2 -O0 -g3 -ggdb3 -Wno-write-strings -D_GLIBCXX_DEBUG
-D_GLIBCXX_DEBUG_PEDANTIC -D_GLIBCXX_CONCEPT_CHECKS
-I/export/home0/wspage/aldor-1.1.0-1/extra/rona/include -Iinclude
-I/export/home0/wspage/aldor-1.1.0-1/include
-L/export/home0/wspage/aldor-1.1.0-1/obj/lib -lport -lgeneral
-lstruct -lphases -ltoplevel -lrona
/export/home0/wspage/aldor-1.1.0-1/src/frontend/aldor.o -lm -ldl -o
/export/home0/wspage/aldor-1.1.0-1/obj/bin/aldor
/usr/ccs/bin/ld: cannot find -lport
collect2: ld returned 1 exit status
make[1]: *** [/export/home0/wspage/aldor-1.1.0-1/obj/bin/aldor] Error 1
make[1]: Leaving directory `/export/home0/wspage/aldor-1.1.0-1/src/frontend'
make[1]: Entering directory `/export/home0/wspage/aldor-1.1.0-1/i18n'
for i in ; do \
make -w --no-builtin-rules $i.build.tag || exit 1; \
done
for i in ; do \
make -w --no-builtin-rules $i.build.tag || exit 1; \
done
MK='/export/home0/wspage/aldor-1.1.0-1/extra/make' INDENT=' '
SRCROOT='/export/home0/wspage/aldor-1.1.0-1' make -w
--no-builtin-rules post-build || exit 1
make[2]: Entering directory `/export/home0/wspage/aldor-1.1.0-1/i18n'
rm -f .depending
make[2]: Leaving directory `/export/home0/wspage/aldor-1.1.0-1/i18n'
make[1]: Leaving directory `/export/home0/wspage/aldor-1.1.0-1/i18n'
-bash-3.00$
> It will be overly verbose, but it will show you exactly what command failed.
> Normally, my makefiles should have shown it to you by themselves, but
> this code doesn't seem to work as well as intended, yet.
I think your makefiles are probably working as you intended. As you
can see after upgrading yacc to bison and fixing the toolchain a
little the build proceeds to the "compiler" step.
The first occurrence of 'error:' in build.log is
/export/home0/wspage/aldor-1.1.0-1/extra/rona/include/rona/strings/scalar.h:711:
error: 'template<class T> typename rona::meta::type_if<void, rona::adt::scalar:
:known_type<T>::value>::type rona::adt::scalar::assign(const T&)' cannot be over
loaded
here is the context:
g++ -g -O2 -O0 -g3 -ggdb3 -Wno-write-strings -fPIC -DPIC -shared -D_GLIBCXX_DEB
UG -D_GLIBCXX_DEBUG_PEDANTIC -D_GLIBCXX_CONCEPT_CHECKS -I/export/home0/wspage/a
ldor-1.1.0-1/extra/rona/include -Iinclude -I/export/home0/wspage/aldor-1.1.0-1/
include -DIN_RONA -c -o /export/home0/wspage/aldor-1.1.0-1/extra/rona/rona/sca
lar.o /export/home0/wspage/aldor-1.1.0-1/extra/rona/rona/scalar.cc
/export/home0/wspage/aldor-1.1.0-1/extra/rona/include/rona/strings/scalar.h:711:
error: 'template<class T> typename rona::meta::type_if<void, rona::adt::scalar:
:known_type<T>::value>::type rona::adt::scalar::assign(const T&)' cannot be over
loaded
/export/home0/wspage/aldor-1.1.0-1/extra/rona/include/rona/strings/scalar.h:704:
error: with 'template<class T> typename rona::meta::type_if<void, (! rona::adt:
:scalar::known_type<T>::value)>::type rona::adt::scalar::assign(const T&)'
/export/home0/wspage/aldor-1.1.0-1/extra/rona/include/rona/strings/scalar.h: In
instantiation of 'rona::adt::visitor::binary_visitor_c<bool, const long int&, ro
na::adt::visitor::addeq_predicate>':
/export/home0/wspage/aldor-1.1.0-1/extra/rona/include/rona/strings/scalar.h:336:
instantiated from 'rona::adt::scalar& rona::adt::scalar::operator+=(const Rhs
&) [with Rhs = long int]'
/export/home0/wspage/aldor-1.1.0-1/extra/rona/include/rona/strings/scalar.h:347:
instantiated from here
/export/home0/wspage/aldor-1.1.0-1/extra/rona/include/rona/strings/scalar.h:195:
etc.
-------
I don't really understand the make scripts yet, but maybe this shows
an uncaught error in the compilation of the RONA library?
Anyway, this is good progress. :-) Thanks for your continued help!
Regards,
Bill Page.
More information about the Aldor-l
mailing list