<s id="ig242"><tt id="ig242"></tt></s>
  • <li id="ig242"></li>
  • <tbody id="ig242"></tbody>
    Bull Atos Technologies

    AIX Open Source Archives


    Gcc multi-versioning support

    GCC packages have been improved in order to support several versions being installed at the same time.
    They have been split into two types:

  • gccX packages providing the GCC version X. It can be installed in parallel with other gccX packages. For example, gcc8-8.4.0-2 is for gcc compiler version 8 with the minor version 8.4.0.
  • gcc packages providing the default GCC, the one used to compile other RPMs. This package is a meta-package having only requirements on its corresponding gccX package and creating links for binaries and libraries.
    In order to simplify everything, gcc doesn't have minor versions anymore. These are managed in gccX packages, which, then, can be upgraded independently.

    Most of the time, you'll just need to install gcc and the correct gccX will be included as a dependency.
    If you're planning to install another gccX, you have to take care about a few things.
  • The default gcc can't be uninstalled nor changed as it's providing the libgcc needed by most of our programs.
  • Be careful when changing the LIBPATH in built binaries and libraries. It must first search for its own version libraries (under /opt/freeware/lib/gcc/powerpc-ibm-aix*/X/...), before searching in the default path (/opt/freeware/lib).
  • Binaries are now suffixed with the version. In order to compile with GCC version 9, you must call gcc-9 or g++-9.

    This support is available starting from gcc-8-1. Note that the Epoch inside the RPM has been incremented to override the previous gcc-9.1.0-1, which don't have this support.
    Currently, only GCC versions after 8 are supporting the multi-versioning. If you wish to have it for GCC 6 or 7, please contact us.

  • 2020-02-25

    Compatibility OpenSSL Removal

    We have started to remove the OpenSource OpenSSL dependency from our RPMs and to use the LPP OpenSSL instead. There is two reasons behind that:

  • OpenSSL 1.0.2 is no longer supported since January 2020.
  • Our OpenSSL was polluted by -bexpall. This introduces huge compatibility problems when anyone want to have a mix of AIXToolbox and BullFreeware RPMs. For the same reason, we can't simply upgrade our OpenSource OpenSSL to version 1.1.X.
    In order to remove OpenSSL, you must install the new version of the RPMs without the dependency (see the list below). You won't be able to remove OpenSSL RPM until all RPMs depending on it have been upgraded or removed. However, the newly LPP-dependent RPMs are compatible with the old OpenSource OpenSSL. That means that you can install our newly LPP-dependant RPMs and still have the OpenSource OpenSSL installed for whatever reasons.
    Note that because of mistakes made on our OpenSSL, it's highly recommanded to reinstall the AIX OpenSSL LPP (cf here) after having erased the RPM.
    Once you have deleted OpenSSL and reinstall the LPP, you will have some residuals from our RPMs under /var/ssl. You can remove without fear /var/ssl/64 and /var/ssl/openssl.cnf.rpmorig

    List of RPMs rebuilt without OpenSSL:
  • bind TODO
  • curl 7.68.0-1
  • cups TODO
  • cyrus-sasl 2.1.27-1
  • git 2.25.0-1
  • httpd 2.4.41-2
  • krb55.18-1
  • libssh2 1.9.0-2
  • libzip 1.6.1-1
  • mariadb-10.4.12-2
  • mariadb-connector-c-3.1.6-1
  • mongo-c-driver-1.16.2-1
  • openldap 2.4.48-3
  • php-7.4.2-2
  • postgresql-12.1-2
  • python 2.7.17-2
  • python3 3.8.1-3
  • python-pycurl
  • ruby 2.6.5-1
  • serf 1.3.9-3
  • sudo 1.8.31-1
  • tcpdump 4.9.3-1
  • wget 1.20.3-3

    We won't rebuild "exim" and "neon" RPMs for now because there aren't supported or needed anymore.

    If you're seeing an error similar to the following one that means that your XXX program comes from a RPM which is still using the OpenSource OpenSSL.
    Could not load program XXX: Symbol resolution failed for XXX because: Symbol _GLOBAL__AIXI_libcrypto_so (number 188) is not exported from dependent module /usr/lib/libcrypto.a[libcrypto.so.1.0.2]. Symbol _GLOBAL__AIXD_libcrypto_so (number 189) is not exported from dependent module /usr/lib/libcrypto.a[libcrypto.so.1.0.2]. Symbol strcmp (number 190) is not exported from dependent module /usr/lib/libcrypto.a[libcrypto.so.1.0.2]. Symbol memcpy (number 191) is not exported from dependent module /usr/lib/libcrypto.a[libcrypto.so.1.0.2]. Symbol memset (number 192) is not exported from dependent module /usr/lib/libcrypto.a[libcrypto.so.1.0.2]. Symbol memmove (number 193) is not exported from dependent module /usr/lib/libcrypto.a[libcrypto.so.1.0.2]. Symbol _GLOBAL__AIXI_libssl_so (number 239) is not exported from dependent module /usr/lib/libssl.a[libssl.so.1.0.2]. Symbol _GLOBAL__AIXD_libssl_so (number 240) is not exported from dependent module /usr/lib/libssl.a[libssl.so.1.0.2]. Examine .loader section symbols with the 'dump -Tv' command.

  • 2020-02-11

    New server

    The website has been moved to a new server.
    Doing so, we have modified the paths where the RPMS are stored, in order to be ready for yum/dnf (which should be available soon).
    Now, RPMS and SRPMS are delivered in two different folders (respectively www.071791.com/packages/RPMS and www.071791.com/packages/SRPMS. RPMS folder is divided between:

  • ppc: packages available for all AIX version
  • ppc-"X": packages built for the specific AIX version "X"
  • noarch: packages without anything compiled
    If you experience any unexpected issue, please warn us through the contact page or by email to bullfreeware@atos.net.

  • 2019-12-11

    Compatibility Improvement

    We have started to remake some of our core RPMs in order to improve our compatibility with both AIXToolbox and future releases. Even if we are doing our best to be compatible with our previous wrongly made RPMS, these updates might break your current setup. We do recommend updating them all at once. If you do encounter any problems, please contact us.

    Here is a list of the changes which may impact you.

    • RPM 4 is now used by default. Systems being in RPM 3 might have some trouble with dependencies made for RPM 4 only.
    • Links between /usr and /opt/freeware aren't made by default anymore. Mixing native AIX and Open Source software was triggering to much problems. You can still add some links yourself if you want.
    • Standalone shared object (.so files) aren't delivered under /opt/freeware/lib(64), anymore. It's not possible to ensure upward compatibility with them. If you need them, you can still extract them from archives (.a files).
    • For developers, .la files aren't delivered anymore. Fedora is doing the same as said in its guideline .

    List of the packages having been modified

    • gettext >= 0.20.1-1 (including subpackage: gettext-devel, libtextstyle, libtextstyle-info)
    • libunistring >= 0.9.10-1 (libunistring-devel)
    • libiconv >= 1.16-3
    • ncurses >= 6.1-3 (ncurses-devel)
    • texinfo >= 6.7-1 (info)
    • zlib >= 1.2.11-3 (zlib-devel)


    Updated CMake

    Starting with version 3.14.* (better with 3.14.3), CMake now correctly handles the specific requirements of AIX, like libtool does. Thus, building an application with CMake on AIX now generates lib*.a files containing lib*.so shared objects. The -bexpall, -G, and -brtl options are no more used by default. .exp export files, with -bE/-bI, can be used now. In some complex case, that requires to change the CMake files of the application. See the readme for more explanations.


    bash v4.4-4

    This new release fixes an issue that was there since ages: when root, the test "test -x file" was returning true (0) even if the file has no exec rights.


    Python v2 and UCS2/UCS4.

    From Python v2.7.12-2 to v2.7.15-3 , we have used unicode=ucs4 instead of ucs2 . For those using Python modules, that should generate issues at execution. We are now back to unicode=ucs2 with Python v2.7.15-4.

    Show archived news

    You can see news that have been archived and might not be relevant anymore here.