On Sep 7, 2014, at 10:03 PM, Ryan Schmidt <[email protected]> wrote:
>
> 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.
Great. btw, it seems that the patch files are no longer necessary, though I
have not yet done enough interoperability testing to be absolutely certain.
I’ll open a ticket at some point to get them to go away.
>
>
>> 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...
>
And never will be. It is written on snow leopard, and involves a problem with
the universal variant which has long since vanished from the Portfile (and will
not be supported in the future unless someone else wants to do a lot of work to
implement an increasingly obsolete feature).
Isn’t there a “won’t fix” resolution possible?
- Tom
_______________________________________________
macports-dev mailing list
[email protected]
https://lists.macosforge.org/mailman/listinfo/macports-dev
