![]() |
> So far I've had include problems with port.h (not liking extern defs of > opendir and cfsetispeed), configure (strftime and socket calls not found in > [...] > > Try figuring out a way that ./configure checks the right places > (libs and include files) for your system and places the needed > defines into port.h (and please provide a patch for ./configure > which doesn't break anything else); I did some of that already. Included a "dir.h" and "sys.h" (I believe--I'm at work now) in port.h to fix a couple problems, redefined LOG_PERROR and STDERR_FILENO, etc. I couldn't figure out a way to "fix" configure without basically customizing it for my system (I changed the initial check for libc to check instead for libsys_s or libMedia_s). Should configure maybe check (in addition to "typical" standard places for any given function) all the libraries in MACHDEPLIBS [or whatever it was called?] I added the appropriate libraries to that def. in config.site, but that only gets used in the make phase, not during configure. As I said, I've managed to work around those, but I'm still having a problem with what I'm certain is good code, I just can't tell 'cause I don't know c++. How can I trace out what the real problem with the compile is? I've even commented out those problem lines [reproduced again below for those who have joined us late ;-)], but got similar errors later in RegExDict. So I'm sure that I've got some basic gcc configuration problem somewhere, but where?!? Thanks in advance! david. > All those I kinda hacked around, and I figure they're okay, though they may > be indicative of more serious problems. Right now I'm stuck on an error while > compiling RegExPtr.c++, which I've traced (with no help from gcc's error > message) to three lines in Array.c++: > ITEM * obj = new(ptr) ITEM; > and > ITEM * obj = new(q) ITEM(*p); [twice] > Now, I'm comfortable (though by no means an expert) with Objective-C, but I > can't make heads or tails of this C++ stuff. What exactly are these lines > trying to do? [in this case, ITEM turns out to be the class(?) RegExPtr]. Why > won't it compile? Here's the output of the make: > .... > = util > /usr/local/bin/gcc -I../../zlib -D__ANSI_CPP__ -I. -I.. -I../../util > -I../../util -I/usr/local/include -I../../regex -g -O > -x c++ -c ../../util/RegExArray.c++ > ../../util/RegExArray.c++: > In method `void RegExArray::createElements(void *, unsigned int)': > ../../util/RegExArray.c++:27: > too many arguments for function `void * operator new(long unsigned int)' > ../../util/RegExArray.c++: > In method `void RegExArray::copyElements(const void *, void *, unsigned > int) const': > ../../util/RegExArray.c++:27: > too many arguments for function `void * operator new(long unsigned int)' > ../../util/RegExArray.c++:27: > too many arguments for function `void * operator new(long unsigned int)' > *** Exit 1 > Stop. > > > I'm running NeXTSTEP 3.2 on motorola hardware, if that helps (which it > probably won't). > > I strongly suspect I'm missing something simple somewhere deep in my > configuration or gcc installation, but not having a clue how c++ works, I'm at > a loss as to where to start. I've been working at this since Saturday, and > have given up hope of solving it myself. Any suggestions??? > > > Thanks! > > david.