Greetings,
I recently tried to build ast-open from source on a 32-bitinstallation
of openSUSE 12.1 with no luck (lots of build errors):
# uname -a
Linux marty.blilly.net 3.1.0-1.2-desktop #1 SMP PREEMPT Thu Nov 3
14:45:45 UTC 2011 (187dde0) i686 i686 i386 GNU/Linux
# package
linux.i386
# echo ${PACKAGEROOT} ${INSTALLROOT}
/opt/ast /opt/ast/arch/linux.i386
I used the architecture-specific rather than flat installation because
I plan to use AST on several machines, some of which are linux.i386-64
(more about that later).
Part of the problem might be related to the installation of the
openSUSE ksh package (ksh has been available as an installation package
under SUSE and openSUSE linux for quite some time). I tried again
without that; still no luck.
Another part of the problem may be that AST doesn't play nicely with
recent versions of gcc.
# gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/i586-suse-linux/4.6/lto-wrapper
Target: i586-suse-linux
Configured with: ../configure --prefix=/usr --infodir=/usr/share/info
--mandir=/usr/share/man --libdir=/usr/lib --libexecdir=/usr/lib
--enable-languages=c,c++,objc,fortran,obj-c++,java,ada
--enable-checking=release --with-gxx-include-dir=/usr/include/c++/4.6
--enable-ssp --disable-libssp --disable-plugin
--with-bugurl=http://bugs.opensuse.org/ --with-pkgversion='SUSE Linux'
--disable-libgcj --disable-libmudflap --with-slibdir=/lib
--with-system-zlib --enable-__cxa_atexit
--enable-libstdcxx-allocator=new --disable-libstdcxx-pch
--enable-version-specific-runtime-libs --program-suffix=-4.6
--enable-linux-futex --without-system-libunwind --with-arch-32=i586
--with-tune=generic --build=i586-suse-linux
Thread model: posix
gcc version 4.6.2 (SUSE Linux)
I say AST doesn't play nicely because I frequently get:
cc1: note: obsolete option -I- used, please use -iquote instead
messages (scores of then during the attempt to build from source) when
using nmake.
Incidentally, I see from
http://www2.research.att.com/~gsf/download/faq.html that the meaning of
"AST" has changed; however
http://www.research.att.com/export/sites/att_labs/software_tools/index.html
still uses the "old" name.
I gave up for now on building from source and installed the binary
linux.i386 and linux.i386-64 versions. I'll post more about some
concerns that I have about the -64 variant in particular this evening.
I'm making the effort this time to climb the nmake learning cureve, and
the documents available from Alcatel/Lucent have helped
(by the way, the latest nmake version there is now 13, not 12 as stated
in http://www2.research.att.com/~gsf/nmake/nmake.html (under Variants)),
but I can't seem to get it to work well with SCCS as described in
Appendix D of the Alcatel/Lucent User's Guide (version 13).
Incidentally, SCCS (which went to Sun) was released as open source some
time ago:
http://mail.opensolaris.org/pipermail/opensolaris-announce/2006-December/000364.html
It is available (from Oracle, which bought Sun) at:
http://hub.opensolaris.org/bin/view/downloads/devpro
and Joerg Shilling has done some porting and updates; see:
http://sccs.berlios.de/
[list readers unfamiliar with SCCS can get a biased overview from the
Wikipedia entry for Source_Code_control_System]
I cannot get the Alcatel Appendix D pattern examples to work with AST
nmake. The best I seem to be able to do is to force nmake to use SCCS
by listing each g-file as a target with its corresponding s-file as
prerequisite and an explicit action block which invokes get. That's
inferior to make (even gmake) [which can at least get the g-file even
w/o a makefile].
Is there a way to get AST nmake to work well with SCCS short of a
bazillion explicit targets?
That's all I have time for now; more details on the -64 variant concerns
later.
_______________________________________________
ast-users mailing list
[email protected]
https://mailman.research.att.com/mailman/listinfo/ast-users
