serf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Stein <gst...@gmail.com>
Subject Re: Please consider dropping scons
Date Fri, 25 Aug 2017 06:54:02 GMT
Hope you have found it. We'll take patches for both serf and Subversion.
Pretty much, all the developers here have commit rights on svn, too :-)

On Wed, Aug 23, 2017 at 10:37 AM, Michael Schultz <
Michael.Schultz@microfocus.com> wrote:

> Nope, apologies, there is a serf-1 in the include directory. It’s
> something else.
>
>
>
> Mike S
>
>
>
> *From:* Michael Schultz
> *Sent:* Wednesday, August 23, 2017 10:31 AM
> *To:* 'Greg Stein' <gstein@gmail.com>
> *Cc:* 'dev@serf.apache.org' <dev@serf.apache.org>
> *Subject:* RE: Please consider dropping scons
>
>
>
> << So, another problem to solve.>>
>
>
>
> Oops, it was not a problem with expat, it is a problem with –with-serf.
> Seems like it is expecting there to be a serf-2 or serf-1 directory within
> the include directory.
>
>
>
> Mike S
>
>
>
> *From:* Michael Schultz
> *Sent:* Wednesday, August 23, 2017 10:12 AM
> *To:* 'Greg Stein' <gstein@gmail.com>
> *Cc:* dev@serf.apache.org
> *Subject:* RE: Please consider dropping scons
>
>
>
> Yes, I patched the SConstruct for all these problems. I also ran into a
> problem where, even though I had successfully build serf, when I tried the
> install of serf, I got an error with a command line option on the cc
> command. The option looked something like:
>
>
>
> -Wl,-rpath=/usr/local/apr
>
>
>
> Which the native HP-UX command did not like at all. (Unfortunately, HP-UX
> wants to place the complete pathname in its shared libraries, so one can’t
> build them and then copy them to their installation. Thus, libtool, and I
> guess SCons, rebuilds the libraries with a new destination directory. I
> think it’s a security thing, but I digress.) To fix this, in the
> Environment, I just placed RPATHPREFIX=’-L’. I was not able to figure out
> why the install worked differently from the build.
>
>
>
> It is hard for me to say that configure is a superior solution though. I
> just ran the build on Subversion and configure is totally messing up one of
> the the –with parameters. So, another problem to solve.
>
>
>
> Mike S
>
>
>
> *From:* Greg Stein [mailto:gstein@gmail.com <gstein@gmail.com>]
> *Sent:* Tuesday, August 22, 2017 7:50 PM
> *To:* Michael Schultz <Michael.Schultz@microfocus.com>
> *Cc:* dev@serf.apache.org
> *Subject:* Re: Please consider dropping scons
>
>
>
>
>
>
>
> On Tue, Aug 22, 2017 at 3:47 PM, Michael Schultz <
> Michael.Schultz@microfocus.com> wrote:
>
> I must admit I had a "I'm not going to let this defeat me" moment this
> morning and learned enough about SCons to fix the SConstruct script. The
> first problem: There was no PATH at all in the environment, so no wonder it
> couldn't find the C compiler.
>
>
>
> Wow. That is really weird. I'm assuming you got this solved? Patched
> SConstruct, or something else?
>
>
>
> Second problem: I built libz and installed it in a local directory, and
> the UNIX bversion of the SERF SConstruct didn't set ZLIB's include and lib
> into CPPPATH and LIBPATH.
>
>
>
> Looks like SConstruct has a ZLIB variable available for Windows builds,
> but it assumes the system include and lib directories otherwise. Seems we
> should obey ZLIB (and OPENSSL, etc) if they are specified on any platform.
>
>
>
> Third problem: expat was included as a library, which I again only
> installed locally, but EXPAT/lib wasn't included in LIBPATH.  (In fact,
> there was no way to specify the directory for EXPAT.)
>
>
>
> Yeah... Expat is a dependency of apr-util, so serf isn't concerned with
> it. I'm going to guess there is a problem with apu-1-config producing some
> incorrect results. Maybe an RPATH issue somewhere? (I'm not familiar enough
> with HP-UX to know if that concept is supported)
>
>
>
> Cheers,
>
> -g
>
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message