py27-omniORBpy pre-built binary trouble

[Ryan Schmidt]

On Sep 7, 2014, at 11:55 PM, Thomas G Lockhart wrote:
> 
> On Sep 7, 2014, at 9:38 PM, Ryan Schmidt wrote:
> 
>> On Sep 7, 2014, at 11:32 PM, Thomas G Lockhart wrote:
>> 
>>> btw, I’ve been occasionally playing with updating omniORB (and omniORBpy) to the latest versions. They have always failed to build and I’d figured it was some breakage in the code for MacOS, but it turns out to be a Portfile problem where /opt/local/include is put on the compiler command line before the build directory paths are listed. If there is an older version of omniORB already installed, and if the include files are not fully compatible, then the build breaks. I’m guessing that it was the stuff added to make sure that the MacPorts compiler flags are used, but the omniORB makefiles are not using things in the expected order. A bad side effect. Will start tracking that down now too…
>> 
>> That should be easy enough to fix by adding one line:
>> 
>> configure.cppflags-replace -I${prefix}/include -isystem${prefix}/include
>> 
>> Will test that now.
>> 
>> For background on this, see https://trac.macports.org/ticket/40656
> 
> Well, we’ve got both omniORB and py-omniORB upgraded to version 4.2.0. Thanks!!!!!!

Yeah those built for me without too much trouble, but I did not have the previous version installed so I had not seen the problem you saw.

Replacing the cppflags as above helped with one error, but another error remained. Rather than try to isolate and fix it, I added a build conflict in r125161.


> Can we close out the issues (including a very old #23558) and get a fresh start on issues for these ports?

#23558 has not been resolved...