[MacPorts] #39773: nginx 1.4.1 build failures with +upload, +google_perftools -- WITH proposed fixes ( ALSO RE: #38968, nginx 1.4.0 update/build fails )

MacPorts noreply at macports.org
Wed Jul 17 04:00:21 PDT 2013


#39773: nginx 1.4.1 build failures with +upload, +google_perftools -- WITH proposed
fixes ( ALSO RE: #38968, nginx 1.4.0 update/build fails )
-----------------------------+--------------------------------
 Reporter:  anthropologoi@…  |      Owner:  macports-tickets@…
     Type:  defect           |     Status:  new
 Priority:  Normal           |  Milestone:
Component:  ports            |    Version:  2.1.3
 Keywords:                   |       Port:  nginx
-----------------------------+--------------------------------
 Filing a new ticket, since this 1) pertains to nginx v1.4.1 and 2) also
 concerns the +google_perftools variant and includes a "fix" for it. Since
 it might be preferable to break the 2 variants / build-failures up, I've
 also included Portfile diffs for each variant's fix alone, and this ticket
 can be switched to just the gperftools issue, and the upload_module fixes
 + discussion + what-have-you can be tacked on to #38968 for just that
 issue.
 ----
 * Ok, regarding the +upload variant build failure, the attached diffs
 allow successful patching and building of the upload_module's lone c-file.
 Bear with me here: The diff was generated using [a] the most recent
 version of the file ( updated for this very issue ) from the "master"
 branch ( renamed from "2.2" ) of [b] ( username ) TimothyKlim's fork of
 [c] the "2.2" branch -- equivalent to what the port uses now ( i.e. NOT
 the "master" branch ) -- of [d] Valery Kholodkov's github repo for this
 module ( vkholodkov/nginx-upload-module ). [ exhale... ]

     The new file used can be accessed at ( caveat: [...]/blob/[...] links
 have a way of disappearing over time. ): [[BR]]
     http://github.com/TimothyKlim/nginx-upload-
 module/blob/b8c1ce8f4f27f51093261d35e3a0376013930c2c/ngx_http_upload_module.c
 ----
 * Next, regarding the +google_perftools build failure, my `ui_warn` msg
 might be too verbose for others' liking, but I was aiming for something
 more enlightening than what's reported when `configure` fails to find any
 libprofiler.[dylib|a] in /opt/local/lib. I can rollback my `portindex`-ed
 Portfile and re-run `port -v configure nginx +google_perftools` if you'd
 like the full log, but here are the essential parts of the `configure`
 test that fails ( from the file [$worksrcpath]/auto/lib/google-
 perftools/conf -- indentation altered for clarity ):[[BR]]
 {{{
 ...

     if [ $NGX_RPATH = YES ]; then
         ngx_feature_libs="-R/opt/local/lib -L/opt/local/lib -lprofiler"
     else
         ngx_feature_libs="-L/opt/local/lib -lprofiler"
     fi

 ...[snip]...

     if [ $ngx_found = yes ]; then
         CORE_LIBS="$CORE_LIBS $ngx_feature_libs"
     else
         cat << END
         $0: error: the Google perftool module requires the Google
 perftools
         library. You can either do not enable the module or install the
 library.
         END

 ...
 }}}
     The google_perftools port does not in fact install any profiler
 components on my OSX 10.7.5 system, only the ( probably multiply-broken )
 `pprof` binary. No error is reported when installing that port -- its
 configure script just shrugs and skips building libprofiler when it can't
 find a needed header. I'll be opening a separate bug + working on fixes
 for the google_perftools port, and I'll report here if the issue proves to
 be my error.

     Anyway, it's *kind of* a moot point, since my patch to nginx's
 +google_perftools variant-routine is written so it only errors out if
 whoever else's system, like mine, ended up with an "installed"
 google_perftools port, but no profiler lib for the module to link to.
 ----
 Last bits:
 * There are 2 versions of the Portfile diff for fixing the +upload
 variant. I used a simple `proc` for Portfile-wide scope-access, in order
 to pass the upload_module's $worksrcpath to `pre-patch` + `post-patch`.
 Using this approach, you only need to set the module's ( actual or desired
 ) $distname/$version/$worksrcdir vars in *1* place, and they just get
 copied around where needed. Since the upload_progress_module's variant-
 routine is substantially the same, I also jimmied in the same logic there.
 If ( cal! ) you'd prefer to leave well enough alone, the Portfile diff
 with "sans-upload_progress-fiddling" in its name omits those changes.
 * Speaking of which, I'm new around here. If the scope-jumping logic, in
 and of itself, is not "Portfile-appropriate", let me know. I'll cut it and
 hard-code the appropriate $distname/$version/$worksrcdir strings wherever
 referenced ( and sigh, sigh, sigh ).
 ----
 I think that's everything...

-- 
Ticket URL: <https://trac.macports.org/ticket/39773>
MacPorts <http://www.macports.org/>
Ports system for OS X


More information about the macports-tickets mailing list