Binary compatibility

Hello all,
I've compiled an app that will run as a service on solaris 8 (on a sparc ultra-5). I've used gcc to compile and the app runs fine on the sparc ultra-5.
My quesion is - will this compiled binary run on an E420 or any other sun hardware? In general, is there some docs/resources that describe binary compatibility across sun hardware?
Thanks for any info.

Hi,
Sun has a very strong binary compatibility guarantee, but I'm not sure where one would find documentation!
I would be more concerned about carting the required GCC runtimes around with you wherever you want to run your binary than Solaris or SPARC binary compatibility.
We build in 32 bit on a quad UltraSPARC III running Solaris 8, using Studio 10 (we were on Workshop 5 until recently!), and most of our customers run on Solaris 9, and in most cases on something a touch faster than UltraSPARC III.
I'd recommend you take a look at the new Studio 11 release (it is free after all) to avoid carting runtimes around with you. Please remember, however, that the machines your software runs on will need to be running at least the same patches as are pre-requisite for Studio 11 (well, the C and C++ runtimes anyway).
-- Michael

Similar Messages

  • Missing package: SUNWbcp (SunOS 4.x Binary Compatibility)

    I have downloaded the latest Free Solaris 10 8/07 for x86 and retrieve the following error message:
    Missing package: SUNWbcp (SunOS 4.x Binary Compatibility)
    when installing Business Objects Enterprise XI Release 2 Service Pack 2. I can't locate the package on neither the CDs nor the DVD I downloaded.
    Any advise would be highly appreciated.
    Many thanks.
    Jurgs
    Edited by: tzscl2 on Dec 12, 2007 12:52 AM

    I have downloaded the latest Free Solaris 10 8/07 for x86 and retrieve the following error message:
    Missing package: SUNWbcp (SunOS 4.x Binary Compatibility)
    when installing Business Objects Enterprise XI Release 2 Service Pack 2. I can't locate the package on neither the CDs nor the DVD I downloaded.
    Any advise would be highly appreciated.
    Many thanks.
    Jurgs
    Edited by: tzscl2 on Dec 12, 2007 12:52 AM

  • Check binary compatibility between 2 Jars

    Hello,
    we have a Java API to our repository product. Is there a way to check binary compatibility between different versions of that API? The problem is that the interfaces evolve and sometimes changes are necessary. So we already had the problem that different versions are incompatible.
    I found just one tool: japitool. But it does not detect the latest problem we have.
    Thanks in advance
    Torsten

    I mean the facts and rules described in chapter 13 of the Java language specification (Binary Compatibility; http://java.sun.com/docs/books/jls/second_edition/html/binaryComp.doc.html#44872).
    Torsten

  • Binary compatibility problems using Sun Studio 12

    I'm working in a project that uses Orbix [1] third-party libraries. I have installed the Sun Studio 12 on Solaris 10 SPARC but I have got some strange segfault problems (the exactly same code works fine in a Linux box - using g++). I read the 1.4 section of Sun Studio 12 C++ Userguide [2] but I have a doubt:
    Is there no way to compile my code using Sun Studio 12 using shared libraries compiled against earlier Sun Studio C++ compiler versions (like Sun Studio 8 or some version before Sun Studio 11)?
    I think my problem is related to the fact that Orbix team used Sun Studio 8 as some notes found in their headers indicate:
    "IONA Technologies ART IDL Compiler POA C++ Generator asp 6.3.3 SunOS 5.8 CC_5.5 2008/06/13 21:04:37 EDT"
    A secondary question: Is CC 5.5 present in Sun Studio 8, right?
    Can anyone help me? Every tips are welcome :) Thanks in advance!
    [1] http://web.progress.com/en/orbix/orbix_standard.html
    [2] http://docs.sun.com/app/docs/doc/820-7599/6nirkt6f7?a=view

    AmadeuBarbosa wrote:
    I'm working in a project that uses Orbix [1] third-party libraries. I have installed the Sun Studio 12 on Solaris 10 SPARC but I have got some strange segfault problems (the exactly same code works fine in a Linux box - using g++). I read the 1.4 section of Sun Studio 12 C++ Userguide [2] but I have a doubt:I don't think 1.4 Binary Compatibility Verification applies in your case. It's referring to processor capability to execute certain (new) instructions; if your third-party libraries were compiled a while ago, it's highly unlikely they use instructions not implemented by the processor you have.
    Is there no way to compile my code using Sun Studio 12 using shared libraries compiled against earlier Sun Studio C++ compiler versions (like Sun Studio 8 or some version before Sun Studio 11)?Generally speaking, any library compiled with older Sun Studio C++ compiler is supposed to be compatible with any library or executable compiled with newer version provided that all parties did everything right. For example, that third-party libraries should not be statically linked with C++ run-time support libraries; your executable should be linked with latest compiler driver (CC) so that it records correct dependencies on support libraries.
    Of course, there could be (and actually are) compiler bugs standing in the way of compatibility. Some of them can be fixed, some - like demangler issue described in http://docs.sun.com/source/820-4155/c++.html - can't. There is no easy way to tell if you hit a compiler bug or bulding/linking issue, or bug in the code that was previously unseen.
    I think my problem is related to the fact that Orbix team used Sun Studio 8 as some notes found in their headers indicate:
    "IONA Technologies ART IDL Compiler POA C++ Generator asp 6.3.3 SunOS 5.8 CC_5.5 2008/06/13 21:04:37 EDT"Yes, looks like it was compiled by 5.5, which is part of Sun Studio 8
    >
    A secondary question: Is CC 5.5 present in Sun Studio 8, right?That's correct.

  • Solaris 8 binary compatibility - Solaris 7

    Greetings:
    and TIA.
    Also apologies if this issue has been covered via some other resource.
    Note: Hardware Utilized - Sparc
    We have recently ported our 4.2 Forte C++/C code successfully from Solaris 6 to Solaris 8. As part of that port, we upgraded the compiler resources from 4.2 to 6.0. With these new binaries we have encountered the following runtime issue:
    Solaris 8 code runs fine on Solaris 8, however these same executables dump core on Solaris 7
    To troubleshoot this, we built the same code on a Solaris 7 platform. These executables ran fine on both Solaris 7 and Solaris 8
    My question: Are Solaris 8 binaries incompatible with Solaris 7? Is there any online documentations which provides an overview/explanation for this behavior?
    Regards:

    In general there is forward compatibility for applications between Solaris releases. There is no official backward compatibility. This means you
    should always compile on the oldest release of
    Solaris that you expectto run on. So, if you need
    to run on Solaris 5.6, 7 and 8, compile on Solaris 5.6.
    There is a tool called appcert which is shipped with
    later versions of Solaris 8 and can be downloaded from:
    http://www.sun.com/developers/tools/appcert/download.html
    That will give you a good idea of the forward and backward compatibility of your application. General ABI information can be found at:
    http://www.sun.com/developers/tools/abi/index.html
    Alan
    Sun Developer Technical Support
    http://www.sun.com/developers/support

  • Solaris 10 binary compatibility

    hello everybody,
    I need some help. my application can run on solaris 2.6 x86 and solaris 9 x86 but not on solaris 10 x86. can anybody suggested to me what are the wor around that I can try to make my application also run on solaris 10 x86.

    That's what I expected, but if you look at:
    http://www.sun.com/software/solaris/ontheinside/
    They say:
    Guaranteed application compatibility from release to release as well as between SPARC and x86 platforms so you can run the same OS from your desktop to your datacenter.
    ???

  • Solaris 10 binary compatibility sparc/x86

    Hi,
    is it possible to use software compiled on Solaris 10 sparc on a x86 system?
    Thanks for any hints in advance.
    Burkhard

    That's what I expected, but if you look at:
    http://www.sun.com/software/solaris/ontheinside/
    They say:
    Guaranteed application compatibility from release to release as well as between SPARC and x86 platforms so you can run the same OS from your desktop to your datacenter.
    ???

  • Binary Compatibility - W2K vs AIX vs Linux

    I have a question. It is posible to move .fmx files compiled on W2K with Forms6i Builder to an Oracle9iAS 1.0.2.2.2 running on IBM-AIX or Linux without to recompile .fmb files created on W2K?.
    Thanks4All.

    If forms are compiled on NT and oracle database is on AIX, after we switch to Sun Solaris, do I need to recompile those forms? if so, can those forms be re-open on Sun Solaris?
    how about reports (.fmb)? currently I compile them on my PC (connect to oracle DB on AIX) and ftp it to AIX, do we need to recompile those reports after platform is changed to SUN?
    thanks in advance!

  • Backward Compatibility

    Hi
    Our application is composed of few data layers. The layers comunicate through interfaces.
    My manager thinks that we should maintain backward compatibility between the layers.
    So:
    There is a defined functional interface "I".
    There is a layer component "L" which provides the functionality of I.
    There is a layer component "UL" which Uses L via I.
    A new layer component "L2" is created which has greater functionality than L and which it exposes via a new interface "I2".
    All the functions of I are also provided by I2. In other words, I is a subset of I2.
    "UL" will provide to a "layer factory" a version number, and the factory will return "L" or "L2" etc.
    This means that we cannot override methods, and difficult maintaining of code as well as code duplication.
    The bennefit of this is that all the components that worked fine with the previous "L" and were not changed, are guarantied to continue working, and needn't any QA.
    What do you think? Does it worth the trouble?
    Thanks,
    Libbhy

    libbysharf wrote:
    The bennefit of this is that all the components that worked fine with the previous "L" and were not changed, are guarantied to continue working, and needn't any QA.Based on what you have stated here, this is not necessarily the case. Just having the same method signatures doesn't not mean that it will work exactly the same way. Even if the methods from L are implemented in the exact same way in L2, you could have situations where the new L2 methods change the behavior of the old L methods.
    What do you think? Does it worth the trouble?Personally, I think it seems a little over-engineered. If you just add to a class, it will not break binary compatibility with existing clients. You'd be much better off spending time creating unit tests and regression test scripts and try to verify that the behaviors from the previous verison are maintained.

  • Will Solaris 8 binary run on Solaris 2.6?

    Hi!
    If a C++ application is compiled on Solaris 8, would it run on Solaris 2.6? Are there any flags that need to be set to get binary compatibility across OS versions? Are the dynamic libraries (Cstd, Crun etc.) binary compatible?
    Any responses would be of great help,
    TIA,
    Mark

    Running applications on older OSes than they were built on is not supported and will often result in problems.
    Just one reason for this is that newer OSes can incorporate functionality and library interfaces (APIs) that do not exist on older OS platforms.
    If compatibility with Solaris 2.6 is needed, then the application should be written to comply with the Solaris ABI (Application Binary Interface) and built on Solaris 2.6. Likewise, if OSes older than 2.6 need to be supported, the application should be compiled on the oldest supported OS.
    Due to Sun's desire to maintain backward compatibility,
    applications which are ABI compliant and are compiled on older OSes should run fine on newer OSes.
    - Rose

  • Sun Compiler Compatibility with g++

    I am new to C++ so I believe this is a basic question.
    I was given the job of compiling a C++ program to be compatible with Sun compiler 5.5 Patch 113817-19 2006/10/13 on Solaris 9 Sparc. Since I did not have the Sun One Studio 8 I compiled the program using G++ 3.4.6. Question: will this program compiled with g++ 3.4.6 satisfy the requirements.
    Any help would be appreciated.
    --Acevez                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                               

    You have to ask those imposing the requirement what they actually care about.
    If you need binary compatibility, the answer is "No." Object code produced from C++ source code by any version of Sun C++ cannot be linked with object code produced from C++ source code by any version of g++.
    If the requirement is that the source code be successfully compiled by Sun ONE Studio 8 (C++ 5.5), the answer is "maybe." Limitations include the following:
    1. Every compiler has bugs. Code might trigger a bug in one compiler but not in a different compiler.
    2. g++ has extensions not supported by Sun C++ 5.5. Source code that uses an unsupported extension probably won't work the same (and probably won't compile) with Sun C++ 5.5. If you write code for use with g++, you might not know when you are using a g++ extension.
    3. The default version of the C++ Standard Library used by Sun C++ is libCstd, which does not fully conform to the C++ standard. Sun C++ also provides the STLport library as an option. Standard-conforming source code that works with g++ and its libstdc++ might not work with Sun C++ libCstd, but will probably work wtih STLport. If you are not allowed to use STLport with Sun C++ and write code for g++, you might write code that depends on features not supported by libCstd.
    In summary, you are asking questions about portability. The short answer is that
    A. C++ object code is in general not portable among C++ compilers, and
    B. You don't know whether source code is portable until you port it.
    That said, most programmers find most of the time that well-written code that has portability in mind works fine with Sun C++.
    Finally, Sun Studio 8 is obsolete. It would be better to use the current release, Sun Studio 11, which is free. You can get it here:
    http://developers.sun.com/sunstudio
    Sun Studio 11 is source and binary compatible with Sun Studio 8, in the following sense:
    Valid source code that works with Sun Studio 8 will also work with Sun Studio 11.
    Object code produced by Sun Studio 8 can be linked into programs built by Sun Studio 11.
    Good luck!

  • Sparc  vs X86 Compatibility

    I installed Solaris 10 to an x86 machine
    I am trying to run some Solaris binaries (probably Solaris Sparc)
    it gives an error
    "invalid argument"
    question is:
    Does not Solaris have binary compatibility? Can't a Sparc binary run on an X86?
    I am totally confused

    What? I thought the whole point of Solaris x86 is that it can run Solaris binaries. So Solaris x86 is not Solaris?
    Is it true that any binary compiled under Solaris on a sparc machine will not run under Solaris x86?
    If true, I completely fail to see the real utility of Solaris x86, at least for my applications, which were all compiled on sparc machines.

  • 5.0 not backwards compatable???

    I just compiled some 1.4.2 code in 1.5, and I got a compiler error. It's not a huge deal, and easily fixable, but I just found it odd that it wasn't backwards compatable. It's suppsoed to be, isn't it?
    It's code that implements Comparable
    public int compareTo(Object o) {
      return toString().compareTo(o);
    }compareTo(java.lang.String) in java.lang.String cannot be applied to (java.lang.Object) at line 92, column 25
    Just incase this was already fixed, I tried compiling this in the latest 1.6.0_01 and I get the same error. The code looked like it was meant to compare the string versions of the objects if the objects were not of the right type. I suppose this case is no longer even valid using generics in Comparable, but like I said, it should still compile if it worked in 1.4.2.

    I just compiled some 1.4.2 code in 1.5, and I got a
    compiler error. It's not a huge deal, and easily
    fixable, but I just found it odd that it wasn't
    backwards compatable. It's suppsoed to be, isn't
    it?No, it's not. Nobody ever said that all code that was compilable with javac 1.4 would be compilable with javac 1.5. Only binary compatibility was guaranteed. That means that you may compile the code you're showing with a 1.4 compiler or with the latest javac if you set the option "-source 1.4".
    After compilation, the generated class file will then be usable by all Java programs, even those compiled with Java 5 or 6.
    BTW, with or without generics, the code looks so highly suspicious that you should be very glad the compiler finally rejects it. To make any sense, it should look like this, which is fine with every Java version:
    public int compareTo(Object o) {
       return toString().compareTo(o.toString());

  • Solaris11 : binary backward compatibilty for old SPARC systems

    We have some decomisisoned SPARC servers that can be used for test & dev, but these are too "old".
    V490, V880, V890 does not support Solaris 11.
    What happened to binary backward compatibilty?
    Oracle sales people commend binary backward compatibility, but I do not get this...

    [opinion]
    To the best of my recollection, "binary compatibility" only refers to software, not to hardware.
    If you had a program or an application that ran on those systems when you had Solaris 9 or Solaris 10 on them, then the same program(s) will install and run on a system that uses Solaris 11.
    For example from a tiotally different part of the computer Universe ---
    I dare you to install Microsoft Windows XP to a computer that happens to have an ISA expansion slot and have that OS recognize the existence of the slot (let alone any cards installed to that ISA slot).
    [end opinion]
    ... now let's see what others might say...

  • Launch SunOs 5.10 Binary on SunOS 5.6

    I compiled a my source on SunOS 5.10 with f95
    and now I try to launch it on SunOS 5.6.
    First some libraries wasn't there, after I copied this libraries on my SunOS 5.6
    I get the following error message:
    ld.so.1: ./sdat: fatal: relocation error: file /usr/lib/libthread.so.1: symbol
    libcthreads_interface: referenced symbol not found
    ld.so.1: ./sdat: fatal: relocation error: file /usr/lib/libthread.so.1: symbol
    libcthreads_interface: referenced symbol not found
    Killed
    Pls, can you help me, what can I do to launch my program on the older SunOS 5.6?
    Thanx and bye
    Jochen

    Sorry, it is hardly possible. Generally the procedure to run binary on a range of SunOS'es is to compile it on the oldest one.
    We provide this kind of binary compatibility, but not backward.
    Compiling on newer OS (10) you make your binary dependant on a newer interfaces which are not available in previous OS versions.
    Thus if you intend to run on Solaris 8, 9 and 10 you should compile on Solaris 8.
    In your case a newer interface you have stumbled upon is a private part of libc threads.
    Solaris 10 is waaay different from previous versions (threading part in particular), you might be lucky with going from Solaris 8 down to 6, but not from Solaris 10.
    Anyway, this questions might be better answered on Solaris forum. They might know some hacks around. Compilers itself cant solve this problem.
    regards,
    __Fedor.

Maybe you are looking for