tao @ 6.3.3 update to newer release

[lockhart (Thomas Lockhart)]

The latest release of TAO (and ACE) is available. Here are simple patches to update the Portfile.

[lockhart (Thomas Lockhart)]

Update from 6.2.6 to 6.3.3

[ryandesign (Ryan Carsten Schmidt)]

Thanks, but this does not build (on Yosemite with Xcode 7):

be/be_visitor_operation/ami_cs.cpp:198:7: error: use of overloaded operator '<<' is ambiguous (with operand types 'TAO_OutStream' and 'ACE_CString::size_type' (aka 'unsigned long'))
      << len << "," << be_nl;
      ^  ~~~
be_include/be_helper.h:173:18: note: candidate function
  TAO_OutStream &operator<< (const ACE_CDR::UShort num);
                 ^
be_include/be_helper.h:174:18: note: candidate function
  TAO_OutStream &operator<< (const ACE_CDR::Short num);
                 ^
be_include/be_helper.h:175:18: note: candidate function
  TAO_OutStream &operator<< (const ACE_CDR::ULong num);
                 ^
be_include/be_helper.h:176:18: note: candidate function
  TAO_OutStream &operator<< (const ACE_CDR::Long num);
                 ^
be_include/be_helper.h:177:18: note: candidate function
  TAO_OutStream &operator<< (const ACE_CDR::ULongLong num);
                 ^
be_include/be_helper.h:178:18: note: candidate function
  TAO_OutStream &operator<< (const ACE_CDR::LongLong num);
                 ^
be_include/be_helper.h:172:18: note: candidate function
  TAO_OutStream &operator<< (const ACE_CString &str);
                 ^
be_include/be_helper.h:184:18: note: candidate function
  TAO_OutStream &operator<< (const TAO_INDENT& i);
                 ^
be_include/be_helper.h:185:18: note: candidate function
  TAO_OutStream &operator<< (const TAO_UNINDENT& i);
                 ^
1 error generated.

[lockhart (Thomas Lockhart)]

Replying to ryandesign@…:

Thanks, but this does not build (on Yosemite with Xcode 7):

be/be_visitor_operation/ami_cs.cpp:198:7: error: use of overloaded operator '<<' is ambiguous (with operand types 'TAO_OutStream' and 'ACE_CString::size_type' (aka 'unsigned long'))
      << len << "," << be_nl;
      ^  ~~~
... }}}

Hmm. Works for me on Yosemite and Xcode 7 (though my testing had been on Mavericks with Xcode 6.2).

I'm rerunning now to preserve the log and determine what compiler is being used for my build. Can you post the command line just before the above error message to show which compiler you are using? Thanks!

[lockhart (Thomas Lockhart)]

...

I'm rerunning now to preserve the log and determine what compiler is being used for my build...

Curious. Here is what I'm using on my Yosemite machine (from inspecting the log during the build process):

$ /usr/bin/clang++ --version
Apple LLVM version 7.0.0 (clang-700.0.72)
Target: x86_64-apple-darwin14.5.0
Thread model: posix

btw, how can I preserve the log after a successful build? "port install -s -k -d" did not do it.

[ryandesign (Ryan Carsten Schmidt)]

Replying to tlockhart1976@…:

...

I'm rerunning now to preserve the log and determine what compiler is being used for my build...

Curious. Here is what I'm using on my Yosemite machine (from inspecting the log during the build process):

$ /usr/bin/clang++ --version
Apple LLVM version 7.0.0 (clang-700.0.72)
Target: x86_64-apple-darwin14.5.0
Thread model: posix

I've attached my log. I'm using the same compiler as you.

btw, how can I preserve the log after a successful build? "port install -s -k -d" did not do it.

Single-letter (i.e. global) flags do nothing unless you place them before the verb ("install" in this case). So you would need to run "sudo port -s -k -d install" or equivalently "sudo port -skd install".

[lockhart (Thomas Lockhart)]

... I've attached my log. I'm using the same compiler as you.

Ah. The compiler flags are different; I've got "-m64" and you've got "-arch x86_64 -arch i386". So you're trying to build a universal binary, or somehow getting in that mode?

I'm installing as "port install tao" with no other qualifications. How are you building this exactly? I'm not recalling much about universal binaries since for most of the ports I've looked at they don't work, and since all supported machines nowadays are 64 bit anyway.

[ryandesign (Ryan Carsten Schmidt)]

Yes indeed, I am using the universal variant. I use this variant by default for all ports; it works for most of the ones I've tried. If you have build failures with the universal variant for which tickets are not already filed you should definitely report those problems.

[lockhart (Thomas Lockhart)]

Replying to ryandesign@…:

Yes indeed, I am using the universal variant. I use this variant by default for all ports; it works for most of the ones I've tried. If you have build failures with the universal variant for which tickets are not already filed you should definitely report those problems.

There is little to no chance that a universal build will ever work for TAO (or ACE, on which it is built). They have many layers all the way down to "universal" bit-level representations in packet communications. In this case the compiler seems to be unable to generate unambiguous code for both 32- and 64-bit machines.

I have a vague (very vague) recollection that this might have been a topic several years ago when I wrote the portfiles for these packages. Very likely you helped me get going at the time!

[ryandesign (Ryan Carsten Schmidt)]

ace built universal just fine. I don't know if the 32-bit part works, but usually I would begin by assuming universal works, until it is proven that it does not.

You mentioned network communications, but network communications should be normalized to an architecture-independent format; hopefully ace/tao has been designed to observe that ​best practice.

If tao cannot build universal, then indicate this by adding the line "universal_variant no" to the portfile. I'm testing a non-universal build now.

[ryandesign (Ryan Carsten Schmidt)]

Replying to ryandesign@…:

If tao cannot build universal, then indicate this by adding the line "universal_variant no" to the portfile.

Actually that's not true in this case. Here, there is no default universal variant, because the port uses "use_configure no". The port deliberately adds a custom universal variant. If that no longer works and cannot be fixed, then the custom universal variant should be removed.

I'm testing a non-universal build now.

This built fine. I committed the update in r140605.

[lockhart (Thomas Lockhart)]

Replying to ryandesign@…:

Replying to ryandesign@…:

If tao cannot build universal, then indicate this by adding the line "universal_variant no" to the portfile.

Actually that's not true in this case. Here, there is no default universal variant, because the port uses "use_configure no". The port deliberately adds a custom universal variant. If that no longer works and cannot be fixed, then the custom universal variant should be removed.

It never worked. I recall (vaguely, as usual) that ACE or TAO may support a universal build but they do so by running the compiler twice on every source file and then merging the object code afterwards. It is not the same scheme as used in MacPorts and I don't think they can be made to work together. And with no 32-bit machines on the market for the last few years I don't know that there is any demand for it anyway.

I'm testing a non-universal build now.

This built fine. I committed the update in r140605.

Thanks!

[ryandesign (Ryan Carsten Schmidt)]

Replying to tlockhart1976@…:

It never worked. I recall (vaguely, as usual) that ACE or TAO may support a universal build but they do so by running the compiler twice on every source file and then merging the object code afterwards.

That strategy is available in MacPorts, in the muniversal portgroup.