On Sep 8, 2014, at 2:21 PM, Ryan Schmidt <[email protected]> wrote:
>
> On Sep 8, 2014, at 2:35 PM, Thomas G Lockhart wrote:
>>
>> On Sep 8, 2014, at 1:05 AM, Ryan Schmidt wrote:
>>
>>>
>>> On Sep 8, 2014, at 12:37 AM, Thomas G Lockhart wrote:
>>>>
>>>> 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.
>>>
>>> I agree the patch for CORBA_sysdep.h is no longer necessary; it was
>>> integrated upstream, but it just so happened that the patch was still able
>>> to apply again, with no harm done. I've removed it in r125162.
>>
>> Great.
>>
>>> The patch for config-darwin.h needs further scrutiny. In fact the
>>> definitions in that file look very suspicious and could be the reason why
>>> the universal build would fail.
>>
>> The build system for omniORB has a lot of history and more recently has
>> autoconf blended in on top of it. I find it pretty impenetrable and would be
>> surprised if we can get a universal build working.
>
> Actually when I tried again, the normal universal build succeeded.
Wow.
>
>> One issue which might make this harder is that the CORBA spec requires
>> specific widths for the integer data types. The implementation probably uses
>> #define constructs to force the right widths depending on the architecture,
>> so having the same code base and just flipping compiler flags may not be
>> enough.
>>
>> I guess that the universal build was claimed to work in the past. But I have
>> no idea if there was any test coverage to verify that the CORBA on-the-wire
>> data widths were in fact correct. I’m skeptical about the whole thing if you
>> haven’t already deduced this ;)
>
> I am skeptical about it too and would want to know whether it was actually
> working. muniversal might be safer. I'll see if I can wire that up, after
> fixing the config file.
Great! Thanks for looking at it. Not sure how I would go about helping to test
though.
- Tom
_______________________________________________
macports-dev mailing list
[email protected]
https://lists.macosforge.org/mailman/listinfo/macports-dev
