[omniORB] omniORB build enviroment
David Byron
dbyron@coactive.com
Thu, 5 Jul 2001 10:45:46 -0700
My current build issues are inspiring me to respond. I'm hoping these are
simple, and I'm just being dense, but here's what I'm running into. The
short answer to the question you ask is, autoconf for the machines/OSes on
which it's easy to support. On other machines, 'manual' config as it is now
may be easier than trying to get something more automated than that to work.
I'm going to try to get omniORB building using configure, etc. to work in
our environment here so hopefully I'll come up with something other folks
can use.
I just downloaded the 3.0.4 tarball and am trying to get it to build on a
Debian 2.2.18pre21 installation. Here's what I think the relevent info
about my environment is:
>From dpkg -l:
ii libc6 2.1.3-18 GNU C Library: Shared libraries and
Timezone
ii libc6-dev 2.1.3-18 GNU C Library: Development Libraries and
Hea
ii python-base 1.5.2-10potato An interactive object-oriented scripting
lan
$ gcc --version
2.95.2
$ g++ --version
2.95.2
$ cpp --version
2.95.3
Here are the mods I've made:
omni/config/config.mk
-- uncommented i586_linux_2.0_glibc2.1
omni/mk/platforms/i586_linux_2.0_glibc2.1.mk
-- commented out BuildSharedLibrary = 1 and added a
BuildSharedLibrary = 0
-- uncommented PYTHON = line and set to /usr/bin/python
-- uncommented CPP = line and set to /usr/local/bin/cpp
-- uncommented include of unix.mk
-- uncommented AR = line
Here's what happens...
omni/src$ make veryclean /* output removed */
omni/src$ make export
making export in src/tool...
make[1]: Entering directory
`/home/dbyron/salem/src/omnisrc-3.0.4/omni/src/tool'
making export in src/tool/omkdepend...
make[2]: Entering directory
`/home/dbyron/salem/src/omnisrc-3.0.4/omni/src/tool/omkdepend'
/usr/bin/gcc -c -O -DDEBUG -I. -I../../../include -D__x86__ -D__linux__
-D__OSVERSION__=2 -o include.o include.c
/usr/bin/gcc -c -O -DDEBUG -I. -I../../../include -D__x86__ -D__linux__
-D__OSVERSION__=2 -o main.o main.c
/usr/bin/gcc -c -O -DDEBUG -I. -I../../../include -D__x86__ -D__linux__
-D__OSVERSION__=2 -o parse.o parse.c
/usr/bin/gcc -c -O -DDEBUG -I. -I../../../include -D__x86__ -D__linux__
-D__OSVERSION__=2 -o pr.o pr.c
/usr/bin/gcc -c -O -DDEBUG -I. -I../../../include -D__x86__ -D__linux__
-D__OSVERSION__=2 -o cppsetup.o cppsetup.c
/usr/bin/gcc -c -O -DDEBUG -I. -I../../../include -D__x86__ -D__linux__
-D__OSVERSION__=2 -o ifparser.o ifparser.c
+ rm -f omkdepend
+ /usr/bin/gcc -o omkdepend -O
-Wl,-rpath,../../../lib/i586_linux_2.0_glibc2.1
-L../../../lib/i586_linux_2.0_glibc2.1 include.o main.o parse.o pr.o
cppsetup.o ifparser.o
File omkdepend hasn't changed.
make[2]: Leaving directory
`/home/dbyron/salem/src/omnisrc-3.0.4/omni/src/tool/omkdepend'
making export in src/tool/omniidl...
make[2]: Entering directory
`/home/dbyron/salem/src/omnisrc-3.0.4/omni/src/tool/omniidl'
making export in src/tool/omniidl/cxx...
make[3]: Entering directory
`/home/dbyron/salem/src/omnisrc-3.0.4/omni/src/tool/omniidl/cxx'
../../../../bin/i586_linux_2.0_glibc2.1/omkdepend -D__cplusplus -D__GNUG__
-D__GNUC__ -DIDLMODULE_VERSION="0x2301" -I/usr/include
-DPYTHON_INCLUDE=<python1.5/Python.h> -I. -I../../../../include -D__x86__
-D__linux__ -D__OSVERSION__=2 idlc.cc idlpython.cc idlconfig.cc idldump.cc
idlvalidate.cc idlast.cc idlexpr.cc idlscope.cc idlrepoId.cc idltype.cc
idlutil.cc idlerr.cc lex.yy.cc y.tab.cc
../../../../bin/i586_linux_2.0_glibc2.1/omkdepend: warning: (from idlc.cc)
/usr/include/bits/stdio_lim.h: 20: # error "Never include <bits/stdio_lim.h>
directly; use <stdio.h> instead."
"idlc.cc":96: __GNUC__ > 2 || (__GNUC__ == 2 &&
__GNUC_MINOR__ >= (defined __cplusplus ? 6 : 4))
^--- expecting )
"idlc.cc":288: (__GNUG__ == 2 && (__GNUC_MINOR__ >= 91 || __GNUC_MINOR__ ==
9)) || \
^--- expecting variable or number
../../../../bin/i586_linux_2.0_glibc2.1/omkdepend: warning: idlpython.cc,
line 291: incomplete include == "#include PYTHON_INCLUDE
"
../../../../bin/i586_linux_2.0_glibc2.1/omkdepend: warning: (from
idlpython.cc) idlpython.cc: 308: # error "omniidl requires Python 1.5.2
or higher" ../../../../bin/i586_linux_2.0_glibc2.1/omkdepend: warning:
(from idlexpr.cc) /usr/include/bits/mathdef.h: 20: # error "Never use
<bits/mathdef.h> directly; include <math.h> instead"
There's more, but I figure dealing with things one at a time makes sense.
>From looking a bit, omkdepend's warning at idlc.cc line 96 is really a
warning about line 96 of /usr/include/assert.h. idlc.c seems to only have
90 lines. Is it possible to have omkdepend display the 'real' filename?
The real question though, is what should I do to fix this? I do see
messages about requires Python 1.5.2 or higher, but from what dpkg is
telling me, I should be OK. Any ideas?
Thanks much for your help. Sorry for the long message.
-DB
> -----Original Message-----
> From: Duncan Grisby [mailto:dgrisby@uk.research.att.com]
> Sent: Thursday, July 05, 2001 10:06 AM
> To: omniorb-list@uk.research.att.com
> Subject: [omniORB] omniORB build enviroment
>
> I've been thinking about how best to re-work the build environment for
> omniORB 4, and I thought I would get some input about what people
> would like, and any suggestions about how to do it.
>
> The current scheme of manually editing a couple of files is
> inconvenient, and can be quite complex if you have things installed in
> different locations to what the defaults expect. This situation is
> going to get worse as optional things like SSL support come along. We
> really need a "configure" stage. We also don't currently have an
> "install" rule, which I know that many people want.
>
> So, there are a few options I can think of:
>
> 1. Autoconf
>
> This would fit with Unix (especially Linux) users' expectations of
> being able to do a simple "configure; make; make install" and
> have everything work. However, autoconf assumes a Unix-like
> environment, so it leaves problems for other platforms. Also, I've
> read the autoconf documentation and I don't understand it in the
> slightest...
>
> 2. A configure stage to the existing build system
>
> We could have a Python script which automatically wrote the
> configuration files required by the current build environment.
> This would be relatively simple, but the current build is getting
> pretty complex, so it might not be that easy in the long term.
>
> 3. A Python script which builds everything
>
> The most radical approach is to write a complete new build system
> in Python, replacing make as well as the configuration stage. The
> Software Carpentry competition
> (software-carpentry.codesourcery.com)
> aimed to create new tools to do this, but it doesn't look like
> there's anything particularly useful to be had from there. This
> would be a lot of work, but it might result in a tool which is
> useful beyond omniORB. It would also make life easier for Windows
> users, since the gnuwin32 tools wouldn't be necessary anymore.
>
> 4. Something else
>
> Does anyone have any comments on any of these? Even better, if
> someone wants to implement something, that would be great.
>
> Whatever happens, we'll keep the existing build environment in
> parallel with a new system, at least until we're certain that the new
> system works.