libproxy 0.4.0 build failure 10.4.11

[yaseppochi (Stephen J. Turnbull)]

I believe this is not the failure in ticket #24127.

Build fails because libraries are expected to be in /Developer/SDKs/MacOSX10.4u.sdk/opt/local/lib, not /opt/local/lib.

I wonder if Apple g++-4.0 on 10.4.11 PPC confuses the -isysroot flag with the --sysroot flag. Or maybe it's CMake weirdness. I've never seen anything like this before.

See attached main.log for details.

I tried setting configure.cc to /opt/local/bin/gcc-mp-4.2 and configure.g++ to /opt/local/bin/g++-mp-4.3 in Portfile, but this fails at the configure stage because the MacPorts compilers don't support the "-arch ppc" flag.

[yaseppochi (Stephen J. Turnbull)]

Correct main.log (the previous one is old, I was fooled by a change in MacPorts naming scheme).

[yaseppochi (Stephen J. Turnbull)]

Oops, transposed digits in the xref. "21427" is incorrect. The correct reference is to #24127.

[jmroot (Joshua Root)]

Please remember to cc the maintainer.

[ryandesign (Ryan Carsten Schmidt)]

Replying to stephen@…:

Build fails because libraries are expected to be in /Developer/SDKs/MacOSX10.4u.sdk/opt/local/lib, not /opt/local/lib.

I wonder if Apple g++-4.0 on 10.4.11 PPC confuses the -isysroot flag with the --sysroot flag. Or maybe it's CMake weirdness. I've never seen anything like this before.

We've seen this many, many times before. It is unique to Tiger on PowerPC. You can workaround the problem by creating the symlink /Developer/SDKs/MacOSX10.4u.sdk/opt pointing to /opt. The correct fix for the portfile is to ensure all the necessary library link statements are present. For example, "can't open dynamic library: /Developer/SDKs/MacOSX10.4u.sdk/opt/local/lib/libenchant.1.dylib referenced from: /opt/local/lib/libwebkit-1.0.dylib" means the library link statement "-lenchant" was missing.

The next problem here is that libproxy shouldn't be using libwebkit at all, since that comes from the webkit-gtk port on which libproxy does not declare a dependency.

[yaseppochi (Stephen J. Turnbull)]

The workaround didn't work, because the link failed.

The link failed because the old libwebkit links in libjpeg.7, which bit the dust quite a while ago.

I tried uninstall -f'ing everything in the dependency chain (webkit-gtk -> libsoup -> libproxy). Of course building that fails dismally because building libproxy does depend on webkit-gtk.

port dependents for libproxy reports only libsoup, for libsoup only webkit-gtk, and for webkit-gtk, none, of course. In fact, 'grep -l webkit' suggests that the binaries for doxygen and a library in wxWidgets-devel link to webkit. Reporting those bugs separately.

[yaseppochi (Stephen J. Turnbull)]

False alarm. Closer examination shows that the hits in doxygen and wxWidgets are not due to linker. I wonder how I got webkit in the first place?

[rmsfisher@…]

Stephen,
Is everything working properly now? If so this ticket could be closed as "worksforme".

[yaseppochi (Stephen J. Turnbull)]

As far as closing this ticket goes, yes, libproxy now builds without complaint, although it issues a warning about "PAC files support not available in Tiger" and refers to #24127. I assume that is expected.

[elelay (Eric Le Lay)]

yes, it is. Indeed, I had to disable PAC support to build libproxy on Tiger.

[bastiaan@…]

I had a similar issue, and I followed the instructions from ​http://permalink.gmane.org/gmane.os.apple.fink.devel/19352 to solve the problem.

[rmstonecipher@…]

Cc Me!

[dbevans (David B. Evans)]

Updated to version 0.4.6 in r71365 which builds properly on Tiger.