qt4-mac @4.8.2_0 +psql91 +universal does not build

[Veence (Vincent)]

During the qmake phase, qt4-mac does not use Macports installed libpq (from PostgreSQL) but the system installed libpq. Since on ML this library is only built for x86_64, building as universal fails.

/usr/bin/llvm-g++-4.2 -headerpad_max_install_names -o psql psql.o     -L/usr/lib -Wl,-syslibroot,/Applications/Xcode45-DP3.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.8.sdk -arch i386 -arch x86_64 -lpq 
ld: warning: ignoring file /Applications/Xcode45-DP3.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.8.sdk/usr/lib/libpq.dylib, file was built for unsupported file format ( 0xcf 0xfa 0xed 0xfe 0x 7 0x 0 0x 0 0x 1 0x 3 0x 0 0x 0 0x 0 0x 9 0x 0 0x 0 0x 0 ) which is not the architecture being linked (i386): /Applications/Xcode45-DP3.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.8.sdk/usr/lib/libpq.dylib
Undefined symbols for architecture i386:
  "_PQescapeBytea", referenced from:
      _main in psql.o
  "_PQunescapeBytea", referenced from:
      _main in psql.o
ld: symbol(s) not found for architecture i386

Note the path of libpq. Same should happen with Xcode 4.4.

[michaelld (Michael Dickens)]

OK; let me reinstall MacPorts using +universal now ... and then I can fix this. !@#$ ML and/or QMake.

[Veence (Vincent)]

IMHO, it is not necessary to rebuild macports with +universal to solve this. The problem must also exist with -universal builds, but goes unnoticed because there is no arch mismatch.

[michaelld (Michael Dickens)]

Yeah; that's certainly true. I usually keep a +universal install around anyway, so it's no big deal. Anyway, it took just a few hours to get to this point, where I can now do such testing. It'll still take me a bit to work out what's going on ...

[michaelld (Michael Dickens)]

What does "port select --list postgresql" return?

[michaelld (Michael Dickens)]

In my testing, this issue happens only when one of MP's postgresql ports is installed, but -not- selected, and then qt4-mac is installed with one of the +psql variants. In this case, the "pg_config" application found is that installed by ML. This issue won't happen when one of MP's postgresql ports is selected, since "${prefix}/bin/pg_config" will be in the path before the ML version (in /usr/bin).

I can fix this by specifying the exact version of "pg_config" to use for the correct variant. But, it'll be highly dependent on where "pg_config" is installed by the port, which right now seems to be "${prefix}/lib/postgresqlXY/bin/pg_config", where "X" and "Y" are the major and minor postgresql version numbers. I'd rather not go this route (semi-hard-coding a path into the configure script), but I cannot think of a better way to do this since there's no guarantee that the user has had port select a postgresql version. Thoughts? Suggestions?

[Veence (Vincent)]

Thanks for investigating. It is my fault then. I think we can safely content with a ui_msg in +psql variants reminding the user to select a postgresql version prior to build with these options. Alternatively, if there is a way to check in the variant code if the corresponding postgresql port is selected or not, and exit in error in the latter case, it would be rad.

[michaelld (Michael Dickens)]

Well, in the qt4-mac Portfile I already create a variable for "psql_version" which works well in "${prefix}/lib/postgresqlXY/bin/pg_config". And, the check, patch, and post-patch were easy to add to "configure" and seems to work for me. So, I'm actually inclined to just do it this way, without having to worry about what the user has selected or not. Doing it this way also guarantees that the correct psql version is selected, regardless of what else the user has installed elsewhere (e.g., in /Library). And, I already have to supply the correct ${compiler.cpath} and ${compiler.library_path} with this information, so why not just also use it during the configure stage?

[michaelld (Michael Dickens)]

Fixed in r96486.