Menu
▾
▴
htdig-dev
|
From: Ted Stresen-R. <ted...@ma...> - 2003-05-28 13:53:07
|
This is the reply I got from Peter O'Gorman when trying to compile htdig on OS X with shared libraries. I don't think he was working on the most recent snapshot, but I'd have to confirm that with him directly. Hope this helps! BTW, excellent work, Jim. You deserve some kind of reward... If you ever pass through Chicago, I'd like to buy you a drink. Ted Stresen-Reuter Begin forwarded message: > From: "Peter O'Gorman" <pe...@po...> > Date: Tue May 27, 2003 11:10:05 PM America/Chicago > To: Ted Stresen-Reuter <ted...@ma...> > Subject: Re: question about your modification to libtool > > Well, after a bit of confusion as to why #include <iostream.h> would > complain about memcpy and memcmp etc not being declared, I went to > bed, woke up, had coffee, made the following change to acconfig.h, and > it all compiled happily with libtool-1.5 > > Thanks, > Peter > > Reasons for this change: > If we do #if HAVE_MEMCMP etc in the @TOP@ section of acinclude, it > will appear before the #define HAVE_MEMCMP.. a bad idea. So instead we > move the @BOTTOM@ tag up about 30 lines and all is well with the > world. > > diff -u -d -b -w -r1.6 acconfig.h > --- acconfig.h 2002/12/31 07:59:02 1.6 > +++ acconfig.h 2003/05/28 00:40:24 > @@ -71,6 +71,7 @@ > /* Define if we should use rxposix.h instead of regex.h */ > #undef USE_RX > > +@BOTTOM@ > /* > * Don't step on the namespace. Other libraries may have their own > * implementations of these functions, we don't want to use their > @@ -101,7 +102,7 @@ > #define vsnprintf __db_Cvsnprintf > #endif > > -@BOTTOM@ > + > > /* > * Big-file configuration. > |
|
From: Lachlan A. <lh...@us...> - 2003-05-29 13:53:52
|
Greetings all, I applied Peter O'Gorman's patch, re-libtooled etc, and no luck :( It may be because the setup on the compile farm is rather messed up,=20 so others are welcome to try it, but I won't be holding my breath. The bad news is that I had to commit the change to get it onto the=20 compile farm (their scp and sftp server is seems to be broken), and=20 the regenerated files don't have the kludges to allow --enable-static=20 --disable-shared to work, so OS X support is back to zero. If anyone wants to re-do those patches, or to undo the latest commit,=20 be my guest. I'm going to bed... Lachlan ZZZzzz... (The good news is that SunOS cc now works.) On Wed, 28 May 2003 23:52, Ted Stresen-Reuter wrote: > > From: "Peter O'Gorman" <pe...@po...> > > > > Well, after a bit of confusion as to why #include <iostream.h> > > would complain about memcpy and memcmp etc not being declared, I > > went to bed, woke up, had coffee, made the following change to > > acconfig.h, and it all compiled happily with libtool-1.5 |
|
From: Ted Stresen-R. <ted...@ma...> - 2003-05-29 14:06:35
|
(Pulling hair out of top of head) AHHHHHRRRGGGGG!!! Ted Stresen-Reuter On Thursday, May 29, 2003, at 08:53 AM, Lachlan Andrew wrote: > Greetings all, > > I applied Peter O'Gorman's patch, re-libtooled etc, and no luck :( > > It may be because the setup on the compile farm is rather messed up, > so others are welcome to try it, but I won't be holding my breath. > > The bad news is that I had to commit the change to get it onto the > compile farm (their scp and sftp server is seems to be broken), and > the regenerated files don't have the kludges to allow --enable-static > --disable-shared to work, so OS X support is back to zero. > > If anyone wants to re-do those patches, or to undo the latest commit, > be my guest. I'm going to bed... > > Lachlan > ZZZzzz... > > (The good news is that SunOS cc now works.) > > On Wed, 28 May 2003 23:52, Ted Stresen-Reuter wrote: >>> From: "Peter O'Gorman" <pe...@po...> >>> >>> Well, after a bit of confusion as to why #include <iostream.h> >>> would complain about memcpy and memcmp etc not being declared, I >>> went to bed, woke up, had coffee, made the following change to >>> acconfig.h, and it all compiled happily with libtool-1.5 > > > > ------------------------------------------------------- > This SF.net email is sponsored by: eBay > Get office equipment for less on eBay! > http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 > _______________________________________________ > htdig-dev mailing list > htd...@li... > https://lists.sourceforge.net/lists/listinfo/htdig-dev > |
|
From: Lachlan A. <lh...@us...> - 2003-05-30 01:33:51
|
On Fri, 30 May 2003 00:05, Ted Stresen-Reuter wrote: > (Pulling hair out of top of head) > AHHHHHRRRGGGGG!!! *sheepish grin* I'm sorry for leaving CVS potentially broken last=20 night, and also very sorry if my email sounded dismissive of OS X=20 users' woes. Needless to say, I was rather tired and emotional... I have backed out the change, it works again on the compile farm. Four=20 tests fail because httpd doesn't work. It used to, but it doesn't=20 on the other computers on the farm, so I assume it has just been=20 disabled... It could well have worked properly with --disable-shared (if the new=20 libtools doesn't need the hacks I put in earlier) but I was too tired=20 to test it. Again, sorry for the frustration caused by the=20 exageration in my email. I think that the problem on the compile farm was that the dynamic C++=20 library doesn't actually *exist* -- not just that it isn't being=20 found. That means that it *should* actually still have worked on a=20 system with that library, and a dynamic zlib (but as my email said,=20 I'm not holding my breath). Could someone who actually has a Mac try Peter's fix (which I think is=20 probably the correct one)? Lachlan |
|
From: Peter O'G. <pe...@po...> - 2003-05-30 02:48:11
|
On Friday, May 30, 2003, at 10:33 AM, Lachlan Andrew wrote: > > I think that the problem on the compile farm was that the dynamic C++ > library doesn't actually *exist* -- not just that it isn't being > found. That means that it *should* actually still have worked on a > system with that library, and a dynamic zlib (but as my email said, > I'm not holding my breath). > That is correct. Apple's gcc does not ship a shared libstdc++ (although this may change with 10.3 and Apple's version of gcc-3.3 (when I built from apple darwin cvs I got a shared libstdc++). I was promised that 10.3 would also include libtool-1.5, but who knows. Any version of libtool < 1.5 will refuse to link a static archive into a shared library on darwin, this was "fixed" in 1.5 by setting the deplibs_check_method to pass_all. What I've seen another project (gnucash) do is to append the entire contents of libtool.m4 to acinclude.m4 and check in a matching version of ltmain.sh to cvs. In their autogen script they run aclocal, automake, autoheader autoconf etc, but do not run libtoolize. This may also work for htdig. libtool issues totally suck :( Peter |
|
From: Jim C. <li...@yg...> - 2003-05-31 05:29:00
|
On Thursday, May 29, 2003, at 07:33 PM, Lachlan Andrew wrote: > I think that the problem on the compile farm was that the dynamic C++ > library doesn't actually *exist* -- not just that it isn't being I checked another OS X box that I know uses a generic install straight off of an Apple CD (installed only a few weeks ago) and found that the dynamic library is not present. Apparently the dynamic version is not standard. I guess the copy I have must have come from one of the Developer Tool downloads, but given the way that it installs it still seems that it is not really intended for general use. Seems that we are probably fighting a losing battle on this one, at least for the time being. We can always add a FAQ telling people to use --disable-shared if it comes up a lot. Jim |
|
From: Geoff H. <ghu...@ws...> - 2003-06-01 03:36:10
|
On Saturday, May 31, 2003, at 12:00 AM, Jim Cole wrote: > the time being. We can always add a FAQ telling people to use > --disable-shared if it comes up a lot. Or we can continue the hack that I put into the configure scripts to set --disable-shared as the default on powerpc-*-* targets. Peter O'Gorman <pe...@po...> wrote: > libtool issues totally suck :( Yes. It would be nice if there were also some easier ways at controlling the libtool macros in configure.in for these purposes. :-( If that sounds like an acceptable solution, let's get the configure, configure.in and various *.m4 files set for release and then I'll go hack away. Cheers, -Geoff |
Thanks for helping keep SourceForge clean.
X