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...
_______________________________________________
macports-dev mailing list
[email protected]
https://lists.macosforge.org/mailman/listinfo/macports-dev
