$ svn info .
Path: .
URL: http://code.ingres.com/ingres/branches/projectD
Repository Root: http://code.ingres.com/ingres
Repository UUID: 45b5d43f-8932-4c86-835a-3654e5842839
Revision: 4279
Node Kind: directory
Schedule: normal
Last Changed Author: adrian_hudnott
Last Changed Rev: 2273
Last Changed Date: 2009-11-23 17:32:09 -0500 (Mon, 23 Nov 2009)

Building the ProjectD branch on OS X is proving to be a challenge. I
got jam and xerces installed, and a much bigger thing called lam-mpi,
which required a one-line patch.

Anybody been here before?

I have many warnings about X, by the way, which I hope won't affect the
server and command-line tools e.g.:

Cc src/cl/clf/csmt_unix/csmtinterf.o
In file included from src/cl/clf/hdr/clsigs.h:127,
from src/cl/clf/csmt_unix/csmtinterf.c:13:
/usr/include/ucontext.h:42:2: error: #error ucontext routines are
deprecated, and require _XOPEN_SOURCE to be defined
src/cl/clf/csmt_unix/csmtinterf.c: In function 'IICSMTadd_thread':
src/cl/clf/csmt_unix/csmtinterf.c:4122: error: 'CS_SCB' has no member
named 'cs_sp' src/cl/clf/csmt_unix/csmtinterf.c:4122: error: 'CS_SCB'
has no member named 'cs_sp'


In file included
from ./src/cl/clf/hdr/clsigs.h:127,
from ./src/cl/clf/cs_unix/csev.c:16: /usr/include/ucontext.h:42:2:
error: #error ucontext routines are deprecated, and require
_XOPEN_SOURCE to be
defined ./src/cl/clf/cs_unix/csev.c:
In function
'CSslave_init': ./src/cl/clf/cs_unix/csev.c:885:
warning: missing sentinel in function call

and quite a few integer-as-pointer warnings. But let's get to the real
trouble: errors.

I'm hip deep in threading, a place for which I'm constitutionally
ill-suited:

Cc src/cl/clf/csmt_unix/csmtinterf.o
In file included from src/cl/clf/hdr/clsigs.h:127,
from src/cl/clf/csmt_unix/csmtinterf.c:13:
/usr/include/ucontext.h:42:2: error: #error ucontext routines are
deprecated, and require _XOPEN_SOURCE to be defined
src/cl/clf/csmt_unix/csmtinterf.c: In function 'IICSMTadd_thread':
src/cl/clf/csmt_unix/csmtinterf.c:4122: error: 'CS_SCB' has no member
named 'cs_sp' src/cl/clf/csmt_unix/csmtinterf.c:4122: error: 'CS_SCB'
has no member named 'cs_sp'

(The root of the problem, of course, is the preprocessor testing for
architecture instead of feature. Search me why they did that. I just
work here.)

Could someone suggest a magic code block for

#if defined (int_osx)

or perhaps a workaround?

Many thanks.

--jkl

On May 14, 2011, at 3:44 PM, James K. Lowden wrote:

Take a look at the main branch. Apparently OSX wants
sys/ucontext.h instead of ucontext.h.

I have no trouble compiling Ingres (main) for OSX in 64-bit
mode, although I get a few warnings about constants too large
when compiling in the (default) 32-bit mode. So you ought to
be able to resolve compilation problems by referring to main.

Karl

On Sun, 15 May 2011 09:37:48 -0400
Karl Schendel <schendel (AT) kbcomputer (DOT) com> wrote:

Karl, thanks for the reply. No joy in main. I get advice to use
darwinports, which I've always found more trouble than it's
worth. Then:

Sun May 15 14:57:14 EDT 2011
warning: unknown rule IISUBSYS
warning: unknown rule IITOOLSSH
warning: unknown rule IITOOLSSH
warning: unknown rule IITOOLSSH
warning: unknown rule IITOOLSBAT
....found 7 target(s)...
../runbuild.sh: line 106: mkjams: command not found
Jamfile: No such file or directory
....found 7 target(s)...
../runbuild.sh: line 128: buildrel: command not found
Sun May 15 14:57:14 EDT 2011

Obviously something basic is wrong. I looked at INSTALL and the wiki;
they were last updated in 2007 and caution not to use gcc 4. (I don't
believe that's still true.) Note to Ingres: It would be nice if the
thing failed more helpfully. Even Google failed to turn up much besides
a guy porting to IBM Linux.

The docs refer to Xerces 2.7, which is known not to compile on Snow
Leopard. :-( I installed current Xerces 3.1.1 instead.

I'm interested in ProjectD for reasons you'll hear more about in June.
So, I went back to that, modified per the attached diff, mostly looking
for missing tests for int_osx (based on looking at main). That didn't
turn out so well because the Xerces writeChars() function is now
virtual, and afaict the handling of it changed completely.

C+
+ /Users/jklowden/projects/ingres/projectD/src/common/adf/adl/UNIMapCompile.o /Users/jklowden/projects/ingres/projectD/src/common/adf/adl/UNIMapCompile.cpp:
In function 'int main(int,
char**)': /Users/jklowden/projects/ingres/projectD/src/common/adf/adl/UNIMapCompile.cpp:335:
error: cannot declare variable 'handler' to be of abstract type
'UNIMapCompileHandlers' /Users/jklowden/projects/ingres/projectD/src/common/adf/adl/UNIMapCompileHandlers.hpp:112:
note: because the following virtual functions are pure within
'UNIMapCompileHandlers': /usr/local/include/xercesc/framework/XMLFormatter.hpp:459:
note: virtual void xercesc_3_1::XMLFormatTarget::writeChars
(const XMLByte*, XMLSize_t, xercesc_3_1::XMLFormatter*)

I understand the message, but I'm a long, long way from knowing what
UNIMapCompileHandlers is for or how to modify ProjectD to live in the
new Xerces world. Sadly, I think that means ProjectD is mostly dead on
the Mac until further notice. (There's a big difference between dead
and mostly dead.)

Which I guess takes me back to main, where my troubles are probably
blindingly obvious. To the sighted, that is.

--jkl

On May 15, 2011, at 3:45 PM, James K. Lowden wrote:


I've never built with runbuild. I'll check over my OSX build
environment tomorrow (I'm excessively wearied today, alas)
and see if I have anything in it that is non-standard. I probably
have something different in my bldenv.

I do remember taking out or otherwise bypassing that darwinports
reference, I never got darwinports to be useful either.

Karl

On Sun, 15 May 2011 18:01:55 -0400
Karl Schendel <schendel (AT) kbcomputer (DOT) com> wrote:

Thanks, Karl. I'm happy to follow what you do. I thought runbuild was
the way.

I got the old xerces 2.7 to build on Ubuntu and, modulo some
inelegant path-discovery in the ProjectD bldenv, have it compiling
there now. Tomorrow we'll know if that works. Or at least I will! ;-)

Regards,

--jkl

Hi James,
When I have seen the unknown rules errors like this has been with a
fresh svn check out and I have not run buildtools/set_env.sh prior to
jamming in src/tools/port/jam; mkjams and then the rest.
Could that be your situation?
Regards,
Ian

-----Original Message-----
From: info-ingres-bounces (AT) kettleriver...ting (DOT) com
[mailto:info-ingres-bounces (AT) kettleriverconsulting (DOT) com] On Behalf Of
James K. Lowden
Sent: 15 May 2011 20:46
To: info-ingres (AT) kettleriverconsulting (DOT) com
Subject: Re: [Info-Ingres] ProjectD on Mac OS X

On Sun, 15 May 2011 09:37:48 -0400
Karl Schendel <schendel (AT) kbcomputer (DOT) com> wrote:

Karl, thanks for the reply. No joy in main. I get advice to use
darwinports, which I've always found more trouble than it's worth.
Then:

Sun May 15 14:57:14 EDT 2011
warning: unknown rule IISUBSYS
warning: unknown rule IITOOLSSH
warning: unknown rule IITOOLSSH
warning: unknown rule IITOOLSSH
warning: unknown rule IITOOLSBAT
....found 7 target(s)...
../runbuild.sh: line 106: mkjams: command not found
Jamfile: No such file or directory
....found 7 target(s)...
../runbuild.sh: line 128: buildrel: command not found Sun May 15 14:57:14
EDT 2011

Obviously something basic is wrong. I looked at INSTALL and the wiki;
they were last updated in 2007 and caution not to use gcc 4. (I don't
believe that's still true.) Note to Ingres: It would be nice if the
thing failed more helpfully. Even Google failed to turn up much besides
a guy porting to IBM Linux.

The docs refer to Xerces 2.7, which is known not to compile on Snow
Leopard. :-( I installed current Xerces 3.1.1 instead.

I'm interested in ProjectD for reasons you'll hear more about in June.
So, I went back to that, modified per the attached diff, mostly looking
for missing tests for int_osx (based on looking at main). That didn't
turn out so well because the Xerces writeChars() function is now
virtual, and afaict the handling of it changed completely.

C+
+
/Users/jklowden/projects/ingres/projectD/src/common/adf/adl/UNIMapCompil
e.o
/Users/jklowden/projects/ingres/projectD/src/common/adf/adl/UNIMapCompil
e.cpp:
In function 'int main(int,
char**)':
/Users/jklowden/projects/ingres/projectD/src/common/adf/adl/UNIMapCompil
e.cpp:335:
error: cannot declare variable 'handler' to be of abstract type
'UNIMapCompileHandlers'
/Users/jklowden/projects/ingres/projectD/src/common/adf/adl/UNIMapCompil
eHandlers.hpp:112:
note: because the following virtual functions are pure within
'UNIMapCompileHandlers':
/usr/local/include/xercesc/framework/XMLFormatter.hpp:459:
note: virtual void xercesc_3_1::XMLFormatTarget::writeChars
(const XMLByte*, XMLSize_t, xercesc_3_1::XMLFormatter*)

I understand the message, but I'm a long, long way from knowing what
UNIMapCompileHandlers is for or how to modify ProjectD to live in the
new Xerces world. Sadly, I think that means ProjectD is mostly dead on
the Mac until further notice. (There's a big difference between dead
and mostly dead.)

Which I guess takes me back to main, where my troubles are probably
blindingly obvious. To the sighted, that is.

--jkl

On May 15, 2011, at 8:31 PM, James K. Lowden wrote:

Ok, I have my bldenv (from $ING_SRC/tools/port/jam) changed to do:

xvers=3.1
export XERCESCROOT=/home/devsrc/treasure/xerces-c-3.1.1
export XERCESLOC=$XERCESCROOT/src/.libs

in the else branch of the test for darwinports, instead of the
complaint message.

I use a private "setingres" script (sourced) which sets ING_ROOT
properly and then sources bldenv. I don't normally run
runbuild or use set_env.sh although I suppose they ought
to work as well.

I have Xerces 3.1.1 installed at the XERCESCROOT above.

After sourcing bldenv, you do the usual incantation of:
cd $ING_SRC/tools/port/jam
jam
cd $ING_SRC
mkjams
jam

with the initial jam and mkjams only needing to be done for a
fresh client, or when something in the directory structure
changes (which is rare).

WIth the default VERS.int_osx you get a 32-bit compile, which
should work, but may spew quite a few warnings when compiling
in cl/clf/mh_unix_win and perhaps a couple other places. If you
copy VERS.int_osx to VERS (this is in tools/port/conf) and make
the indicated changes to compile 64-bit, the warnings disappear.

I don't see any other particularly interesting changes. I see that
I have gtk_need set to "false" but I don't know if that is the
default or something I jiggered locally. My gcc is 4.2.1 and
OSX is 10.6.7 (uname -r reports 10.7.0).

Karl

On Mon, 16 May 2011 05:28:31 -0400
"Ian Kirkham" <Ian.Kirkham (AT) ingres (DOT) com> wrote:

Hi Ian,

I might be missing something, but I don't think that's the problem.
Revision 4279 of runbuild.sh sources buildtools/set_env.sh on line 77.

I'll try Karl's suggestions later.

I almost got ProjectD built under Linux last night, but dived into
looking for g++-3.4 (specifically) when dealing with the xerces
UNIMapCompile.cpp file. Looks like that was always a hard spot. :-/

Regards,

--jkl

I don't use darwinports or any other packaging tool for Mac OS/X.
There are some fixes I made to the Mac port which are not in main yet.
I'll try to find some time today and gather up the important ones and
post.


--
daryl.monge (AT) ingres (DOT) com
------------------------------------------------------------------------
daryl.monge (AT) ingres (DOT) com's Profile: http://community.ingres.com/forum/member.php?userid=736
View this thread: http://community.ingres.com/forum/sh...ad.php?t=13309

On Mon, 16 May 2011 05:28:31 -0400
"Ian Kirkham" <Ian.Kirkham (AT) ingres (DOT) com> wrote:

Hmm, nothing like coffee to make a log clearer.

It looks like runbuild doesn't build buildrel:

$ ./runbuild.sh
....
RESULTS:
All compile targets were successful.
All compile targets were executed.
buildrel -a failed.

The build failed. Check the logs to determine why.
Logs are
in: /Users/jklowden/projects/ingres/main/logs/jam_05_16_11_0945.log

$ grep buildrel logs/jam_05_16_11_0945.log
../runbuild.sh: line 128: buildrel: command not found

This bug was closed a year ago:

http://www.mail-archive.com/bugs (AT.../msg00060.html

--jkl