Opened 9 years ago

Closed 8 years ago

Last modified 8 years ago

#48901 closed update (fixed)

tao @ 6.3.3 update to newer release

Reported by: lockhart (Thomas Lockhart) Owned by: macports-tickets@…
Priority: Normal Milestone:
Component: ports Version: 2.3.3
Keywords: haspatch maintainer Cc: ryandesign (Ryan Carsten Schmidt)
Port: tao

Description

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

Attachments (2)

Portfile.diff (877 bytes) - added by lockhart (Thomas Lockhart) 9 years ago.
Update from 6.2.6 to 6.3.3
main.log.bz2 (16.7 KB) - added by ryandesign (Ryan Carsten Schmidt) 8 years ago.

Download all attachments as: .zip

Change History (13)

Changed 9 years ago by lockhart (Thomas Lockhart)

Attachment: Portfile.diff added

Update from 6.2.6 to 6.3.3

comment:1 Changed 8 years ago by ryandesign (Ryan Carsten Schmidt)

Cc: ryandesign@… added

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.

comment:2 in reply to:  1 ; Changed 8 years ago by 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!

comment:3 in reply to:  2 ; Changed 8 years ago by 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.

Last edited 8 years ago by ryandesign (Ryan Carsten Schmidt) (previous) (diff)

Changed 8 years ago by ryandesign (Ryan Carsten Schmidt)

Attachment: main.log.bz2 added

comment:4 in reply to:  3 ; Changed 8 years ago by 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".

comment:5 in reply to:  4 Changed 8 years ago by 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.

comment:6 Changed 8 years ago by 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.

comment:7 in reply to:  6 Changed 8 years ago by 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!

Last edited 8 years ago by lockhart (Thomas Lockhart) (previous) (diff)

comment:8 Changed 8 years ago by 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.

comment:9 in reply to:  8 ; Changed 8 years ago by ryandesign (Ryan Carsten Schmidt)

Resolution: fixed
Status: newclosed

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.

comment:10 in reply to:  9 ; Changed 8 years ago by 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!

comment:11 in reply to:  10 Changed 8 years ago by 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.

Note: See TracTickets for help on using tickets.