Forte 6U2 - patch confusion

While trying to update our compiler to the newest patch set, I ran into the following problem. From access1, patch 111683-14 requires patch 111690-10 or greater to be installed. 111690-10 is not listed on access1 as a patch. When I tried to install 111690-10 after getting it from sunsolve, the patch installation failed, saying that "One or more patch packages included in 111690-10 are not installed on this system."
111690-10 appears to be an update to the Fortran subcomponent of Forte 6U2, (I guess contained in the Hi-perf package), which we did not install, because we don't use fortran. But this is sort of a problem, because it means that we can't install the latest debugger patch.
Any suggestions?

You can find 111690-10 from access1 at:
http://access1.sun.com/patch.public/cgi-bin/show_list.cgi/wrk/Forte_Fortran_6u2_SPARC
With the next dbx patch release, the dependency problem will be removed. Please wait until the next dbx patch comes out.
- Rose

Similar Messages

Patch problem with Forte 6U2?

I just installed all of the patches currently up at access1 for Forte 6U2 on solaris 8. When I rebuilt, I got the following
Error: The destructor name must match the class name.
while building the following code fragment:
   template<typename T>
   class table
      class node {
      public:
               explicit
         node(const T&);
         ~node();
              // ... other stuff
      // ... other stuff
   // much later in same header
          template<typename T>
          inline
    table<T>::node::~node()
    }The error occurs on the out-of-body inline delcaration of table<T>::node::~node() above.
This code compiled fine with previous patches, and works correctly under gcc3.1 and gcc3.2.
CC -v gives me:
CC: Sun WorkShop 6 update 2 C++ 5.3 Patch 111685-10 2002/09/16
Any information would be appreciated.
Thanks.

I think you and I have different definitions of "status".
Search Failed == Not Fixed seems like a pretty coarse status measurement to me, and a poor interface to boot. If I had a support contract, would I actually be able to read a description of the bug as it is currently filed from suns perspective? What could possibly be so expensive about giving read access to an existing defect database ( esp. when compared with the cost of fixing defects ) that you need to charge to underwrite it? Does it not strike you as almost punitive to require payment from those users who found, tested, and submitted defects for the right to track the status of those defects? Please, please, please explain the rationale behind this to me. I find the whole approach infuriating, unnecessarily opaque, and counterproductive.
Am I interested in finding out that the defect is fixed. Yes. But what is far more important to me is to know that you are actually doing something about it. This critical piece of information is sorely lacking in the current system, especially given the number of defects I have submitted, which were assigned bug IDs, but which have never been fixed in any patch.
http://sunsolve.sun.com is the website you could check
the status of the bug. Search for the bug ID, if it's
not found, then the patch for it is not released.
Otherwise, you will see the patch ID. I don't think
you need to have contract to surf the website.
- Rose

Forte 6U2 - poor performance of std::map::operator[]

I discovered to my horror this morning that Forte 6U2 implementation of std::map (at least at the patch level I'm working with) ALWAYS default constructs a value_type when operator[] is invoked - even if value_type already exists in the map.
Any reasonable STL implementation first uses lower bound to search, and failing to find an appropriate element, uses the resulting iterator as an insertion hint, only then default constructing a value_type (and therefore a mapped_type) element.
The existing implementation in Forte 6U2 imposes an absurd penalty on the use of the subscript operator when mapped_type's default construction semantics are non-trivial. While "correct" in the sense that the contract for std::map::operator[] is met, I cannot imagine that this was an intentional design choice given the performance implications. How can I get this issue addressed?

Well, I wasn't making any claim about the efficiency of the underlying tree representation - only the fact that operator[] unconditionally default constructs a mapped_type object, even if there is already an appropriate element in the map, which is no good at all. I'll try your request for enhancement thing though...
While I would very much like to switch to using STLport vs. the RW stl, a compiler upgrade is not the answer here.

Problem with variadic macros, Forte 6U2

The following code demonstrates a problem with namespace qualifiers used in variadic macros. The workaround (if you want to call it that) is to use triple colons as the scope resolution operator inside certain cases of variadic macros. The following piece of very contrived code demonstrates the problem. If you look at preproccessed output, its pretty clear that the variadic macro eats colons.
unix experiments/C++/badmacros> cat badmacros.cpp
/*************** badmacros.cpp *******************/
#define INTERFACE(ifc) virtual public ifc
#define EXTENDS(...) __VA_ARGS__
namespace foo {
namespace bar {
   class Interface {};
}//namespace bar
}//namespace foo
#if !defined(HACK_TO_FIX)
   class DerivedInterface : EXTENDS( INTERFACE(::foo::bar::Interface) )
#else
   class DerivedInterface : EXTENDS( INTERFACE(:::foo:::bar:::Interface) )
#endif
int main(int argc, char* argv[]){}
/*************** badmacros.cpp *******************/unix experiments/C++/badmacros> CC badmacros.cpp
"badmacros.cpp", line 18: Error: Identifier expected instead of ":".
1 Error(s) detected.
unix experiments/C++/badmacros> CC -DHACK_TO_FIX badmacros.cpp
unix experiments/C++/badmacros>

OK - that is good to hear. OTOH, I think I've found another one. The following code builds properly whether or not DEFINE_IN_CLASS_BODY is set on both g++ 3.0.1 and on the online comeau C++ compiler. However, in Forte 6U2, if DEFINE_IN_CLASS_BODY is not set, compilation fails.
unix experiments/C++/over_template> cat over_template.cpp
#if defined(DEFINE_IN_CLASS_BODY)
class Factory {
public:
   void * create() const {
      return new int;
   template<typename T> T * create() const {
      return reinterpret_cast<T*>(create());
#else
class Factory {
public:
   void * create() const;
   template<typename T> T * create() const;
inline void * Factory::create() const {
   return new int;
template<typename T> inline T * Factory::create() const {
   return reinterpret_cast<T*>(create());
#endif
int main(int argc, char * argv[]){}unix experiments/C++/over_template> \rm -rf SunWS_cache/; CC over_template.cpp
"over_template.cpp", line 30: Error: Factory::create() const already had a body defined.
1 Error(s) detected.
unix experiments/C++/over_template> \rm -rf SunWS_cache/; CC -DDEFINE_IN_CLASS_BODY over_template.cpp
This last compile works fine. Using Forte6U2, all the latest patches installed.

Forte 6u2 mutex creation problem when debug

Hi,
I want to debug my software using forte 6u2 graphical environment but it does not work. When debugging in the graphical env, my software is not able to create some mutex and I can't even step in the code. If I use dbx command line, it works perfectly. Anybody knows what the problem is ?
Thanks,
P.S. My software is pretty huge and uses many dynamic lib.

Can you supply some more details?
When you say your program can't create a mutex, what does that mean? Do you
mean that you are calling pthread_mutex_init() and the function is returning
an error?
When you say you can't "step" in the code, what does that mean?
1. you stop somewhere
2. you hit the "step" button
3. then what happens?
a) program continues without stopping at the line you wanted it to?
b) program doesn't seem to advance anywhere, as if step command was ignored?
c) program crashes?
d) debugger crashes?
Please explain in more detail.
--chris

Forte 6U2 C++ compiler bug

In the Forte 6U2 compiler, a function return can implicitly invoke a conversion constructor that is marked "explicit".
Consider:
class ABaseClass {};
template<class Type, class Uncert>
class Value
public:
     Value(Type const& t, Uncert const& u) : _t(t), _u(u) {}
protected:
     Type       _t;
     Uncert    _u;
class Foo : public Value<float, double>, public ABaseClass
public:
     explicit
     Foo(ABaseClass b=ABaseClass(), float val=-1, double tol=0)
         : ABaseClass(b), Value(val, tol)
         std::cerr << "Explicit constructed Foo\n";
class Bar : public Value<int, double>, public ABaseClass
public:
     explicit
     Bar(ABaseClass b=ABaseClass(), int val=-1, double tol=0)
         : ABaseClass(b), Value(val, tol)
         std::cerr << "Explicit constructed Bar\n";
class Context
public:
     Context() : _foo(ABaseClass(), 1.23, 0.45) {}
     Bar getFoo() const
         return _foo;
private:
     Foo _foo;
int main()
     Context c;
     c.getFoo();
}Note that Context::getFoo has a type mismatch between the declared return type and the return value. This is a bug that was not caught by the compiler. Intstead, Bar(static_cast<ABaseClass>(_foo)) is invoked and
returned. The output of this run is:
Explicit constructed Foo (Context constructor)
Explicit constructed Bar (Context::getFoo return)
This behavior is non-standards conforming.

-xO2 is enough to cause the failure.
Making the vulnerable pointer "static" fixes the problem, although this should make no difference.
My guess is over-eager register reuse, but I'm open to alternative theories.

Template Template Parameters, Forte 6U2, Forte 7EA

Forte 6U2 does not support template template parameters. I had hoped to see support added in Forte 7 early access, but they are not supported in that release either.
While some may argue that template template parameters are the height of C++ esoterica, very sophisticated and usefull libraries like Loki (by Alexandrescu) require them. There are compilers on the market that are capable of handling this construct, and Lippman, who is now at Microsoft, has commited to supporting Loki, Blitz and Boost in future releases of the compiler (see http://www.codeproject.com/interview/stanlippman14nov2001.asp?print=true ). This suggests that microsoft will soon support template template parameters as well.
I would be interested to see if other people who read this forum care about this issue at all, and if so, please respond so we can try to get Sun to do something about this...

I absolutely agree that Sun must keep pace with [if not lead] industry and provide the full suite of C++ language features.
I, too, have spent many hours with Forte C++ 5.3 trying to employ the techniques described in Alexandrescu's "Modern C++ Design" and implemented in his "loki" library. Even recursive template specializations seem not to be supported, though I must do further investigation to confirm.
And it would be nice if the compiler recognized what I was trying to do and issued a "feature XYZ not yet supported" message.
... Dave

GB legislative patch confusion

We went live on HR and Payroll in March (11.5.10.2), so of course I then had to look at legislative patches.
Having found note 145837.1, I though this was not too bad, but I am now getting confused.
Just wondered if anyone else has gone through the following and can offer me any advice ....
1) In the past month or so, patches 6652235, 6825361 have appeared under 11i RUP2 for GB (145837.1) and are still listed in the Change History, but are no longer in the GB section. Why is this ? They do not appear to be have been included in other patches.
2) I have today found note 123810.1 (Oracle UK Payroll 11i Mandatory Patches). This lists 6811030 - P46 Car Changes, but these P46 updates also appear to be in 6652235.
Do I need both or just 6652235 ?
3) Similarly, note 123810.l mentions 6786778 (P11D Legislative changes), but these also appear to be in 6825361
If anyone can point me in the right direction I would appreciate it.
Regards,
Colin

Hello,
The communication from Oracle Payroll UK suggests to apply GB Legislative Patch 6825361 (a HRGlobal patch) and 6786778 (for P11D). 6652235 seems to be an older version of 6825361.
As you went live only this March, I think you may have to generate P11D from legacy system. If that's the case then 6786778 can wait.
Please note that Patch 6899505 is another patch for budget changes. The new tax rate is effective from 18-May-2008 and this patch must go into production before that.
Regards,
Balu

Ghost Vulnerability patching confusion

Hi all,
We are currently running ACS v5.4 and were looking to go to patch 7 initially to combat shellshock.
Then GHOST came along so we waited for Cisco's advisory on the best version to go to.
This has now come out and the advisory is less than helpful!!! - https://tools.cisco.com/bugsearch/bug/CSCus68826
On one habd it seems to say 5.4 is good and on the other that all versions are vulnerable!
Can anybody clarify what patch/version we need to negate the vulnerability please :)
Document is too confusing!!!
Tim

Hi Tim,
I have double checked and all 5.x versions are affected. The fixes are not available for 5.4 or 5.3 but 5.5 and 5.6. Kindly upgrade to get the fixes.
Regards,
Kanwal
Note: Please mark answers if they are helpful.

Quarter Patch Confusion

Hi All,
Client has requested to apply a second quarter patch.
However the quarter patch is yet released now.
As per the oracle doc, The quarter patches dates are following.
From the below patches which one is the 2nd quarter patches.
17 July 2012
16 October 2012
15 January 2013
16 April 2013
Environment information:
OS : RHEL 5
Db : 11.1.0.7
Please Suggest.
Thanks and Regards,

Hi;
From the below patches which one is the 2nd quarter patches.
17 July 2012
16 October 2012
15 January 2013
16 April 2013Critical Patch Update - January 2012 << 1th quarter
Critical Patch Update - April 2012 << 2th quarter
Critical Patch Update - July 2012 << 3th quarter
Critical Patch Update - October 2012 << 4th quarter
Regard
Helios

Patch confusion again

Hi hussein,
I have two (2) instances of EBS 11i named DEV and DEV2. Installed them both separately using rapidwiz.
Scenaro 1:
a) I applied patchA to DEV.
b) I copied the data only (proddata) to DEV2, and run rapdiclone so that the DEV2 instance have the DEV1 database. I mean their database contents are identical, but the appstiers are not because patchA was not applied to DEV2 apps tier side.
My question is can I apply patchA to DEV2 instance just to update the appstier side or the forms executables?
thanks a lot

Hi xyes;
I have two (2) instances of EBS 11i named DEV and DEV2. Installed them both separately using rapidwiz.Those ebs has same patch level?
Scenaro 1:
a) I applied patchA to DEV.
b) I copied the data only (proddata) to DEV2, and run rapdiclone so that the DEV2 instance have the DEV1 database. I mean their database contents are identical, but the appstiers are not because patchA was not applied to DEV2 apps tier side.You mean you run preclone on DEV on dbtier than copy from DEV to DEV2, then post clone db succeded and db is up, so yes we can say DEV db=DEV2 db,but what happen DEV2 original DB?
Regard
Helios

Sun Forte 6U2 Compiler Not Responding....

Hello All,
I am using Sun WorkShop 6 update 2 C++ 5.3 Patch 111685-19 2003/12/18 to build my application Solaris 5.7.
Earlier it was building properly. But suddently Compiler getting hang after it build some files.
No Error Message is printed and nothing happens.
Can You please help me in figuring out what is happening.......

There could be several things going on. If you are the only
one compiling then you may want to clean out the template
cache repository and see if that helps. Try removing all
the SunWS_cache directories where you are building
the object files and see if that helps.

Compilation: SunOne any faster than Forte 6U2?

Hi,
We have Forte C++ 6 update 2 and find compilation is very slow (7-90 seconds per file) compared to the NT platform (second per file). Is the new version (SunOne) any better?
Patrick

I am using a SUN Fireblade 100 with a single 450 MHZ processor and 1GB RAM. What worries me is that on the thread 'Re: Build/Complie times extremely slow...' from February 2002 mentions that a Wintel box will significantly outperform an ultrasparc (see that thread for details).
Yes, pch is turned on on windows.
We use Boost.build (a jam derivative) as our make tool.
Running CC with -xtime shows that the compilation process is mainly cpu bound.
Patrick

CPUJul2010 Patching Confusion

I have installed Grid Control 11.1.0.1 on RHEL 5 64-bit and it is working fine (as far as I can tell). Now that the CPUJul2010 is out, I applied this to several servers, yet the number of "Security Recommendations" have not changed. In GC 10.2.0.5, the number of Oracle Homes would reduce when a CPU was applied. In GC 11.1.0.1, they count the number of databases (or other related objects) running from that Oracle Home, and yet the CPU was applied and the number is not reduced. Anyone have any pointers of where I can look? Trying not to open a SR, but I will if I have to.
Thanks
//Karl

Sorry for not being complete in my original posting. Yes, the job does a host refresh, and then I did one by hand. Thinking it was some other process, I waited overnight, and came in this morning, and sure enough the number of Security Recommendations have not changed. When I click on the number, it takes me to a hybrid of Grid Control and My Oracle Support, where it shows each database (if that is what is on your Recommendation list), the server, and which patch it thinks you need to apply. I just want the databases in which I applied this patch to disappear off this list and any help would be appreciated.
Thanks
//Karl

Is sunONE the same things as forte?

is sunONE the same things as forte? iam confused.

a bunch? what else belongs to sunONE?
and i read in the installer forte was developed from netBeans or so. to make things even more confusing i once (1 year ago or so) tried forte and it looked not like forte today (if i remember correctly).
can it bee that forte simply dropped its ide and adopted the ide from netbeans, and changed only details?
this would be like the filesharing tool mopheus which now is only a exact clone from gnucleus and it dropped its old gui.
is here somebody who knows how the history in the java ide's developed over time? this is very interesting! there is a lot of inheritance and aliases involved, you know :-)

Forte 6U2 - patch confusion

Similar Messages

Maybe you are looking for