#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