Discussions
Categories
- 196.8K All Categories
- 2.2K Data
- 238 Big Data Appliance
- 1.9K Data Science
- 450.2K Databases
- 221.7K General Database Discussions
- 3.8K Java and JavaScript in the Database
- 31 Multilingual Engine
- 550 MySQL Community Space
- 478 NoSQL Database
- 7.9K Oracle Database Express Edition (XE)
- 3K ORDS, SODA & JSON in the Database
- 544 SQLcl
- 4K SQL Developer Data Modeler
- 187K SQL & PL/SQL
- 21.3K SQL Developer
- 295.8K Development
- 17 Developer Projects
- 138 Programming Languages
- 292.5K Development Tools
- 107 DevOps
- 3.1K QA/Testing
- 646K Java
- 28 Java Learning Subscription
- 37K Database Connectivity
- 154 Java Community Process
- 105 Java 25
- 22.1K Java APIs
- 138.1K Java Development Tools
- 165.3K Java EE (Java Enterprise Edition)
- 18 Java Essentials
- 160 Java 8 Questions
- 86K Java Programming
- 80 Java Puzzle Ball
- 65.1K New To Java
- 1.7K Training / Learning / Certification
- 13.8K Java HotSpot Virtual Machine
- 94.3K Java SE
- 13.8K Java Security
- 204 Java User Groups
- 24 JavaScript - Nashorn
- Programs
- 437 LiveLabs
- 38 Workshops
- 10.2K Software
- 6.7K Berkeley DB Family
- 3.5K JHeadstart
- 5.7K Other Languages
- 2.3K Chinese
- 171 Deutsche Oracle Community
- 1.1K Español
- 1.9K Japanese
- 232 Portuguese
MySQL 8 and Solaris 11.4, x86
Answers
-
Didn't know "mysql-8.0.26-solaris11-x86_64.pkg.gz does not exist".
-
While trying to build an IPS package of MySQL 8.x for Solaris x64, I've always been working on MySQL 8.0.26. I use GCC 10 and I seem to get along without the Developer Studio compiler. Currently, I've been stuck in testing, but I am confident to get this resolved.
Today, I discovered by accident that MySQL 8.0.27 has been released to the public in the meantime. So, I've changed "8.0.26" to "8.0.27" in the Makefile which downloads, unpacks and patches the sources.
The end of the story: 8.0.27 did not compile anymore... :-(
But why?
Obviously, the MySQL developers used the release of 8.0.27 to actively prohibit compilation on Solaris x64. The following patch fixed it:
[email protected]:~/solaris-userland/components/mysql-8-0$ cat patches/allowIntel.patch --- mysql-8.0.27/cmake/os/SunOS.cmake 2021-09-28 13:46:34.000000000 +0000 +++ mysql-8.0.27/cmake/os/SunOS.cmake 2021-10-24 10:32:59.300620257 +0000 @@ -28,7 +28,7 @@ IF(CMAKE_SYSTEM_PROCESSOR MATCHES "sparc") SET(SOLARIS_SPARC 1) ELSE() - MESSAGE(FATAL_ERROR "Solaris on Intel is not supported.") + SET(SOLARIS_INTEL 1) ENDIF() IF("${CMAKE_C_FLAGS}${CMAKE_CXX_FLAGS}" MATCHES "-m32")
Has anyone reading here found what their objectives are? It seems that -for now(!)- this little patch seems to enable the compilation again. But it reminds me quite strongly to JDK 15 where https://openjdk.java.net/jeps/381 removed the Solaris support... :-(
Kind regards,
Steffen
-
While 8.0.27 does compile after doing this little above-mentioned patch, it seems that further reverse patching could be needed. The patch reverses only one piece of this large set of changes which broke the compatibility with Solaris on x86-64:
What I do not grasp: Why is such a drastic change not announced in the release notes of MySQL 8.0.27?
They cease supporting one of their own actively developed and maintained operating systems on a still-available server platform and do not mention this in one single word? The only phrases about this change are:
MySQL now can be compiled using C++17. The following minimum version requirements apply for compiler support:
GCC 7.1 or Clang 5 (Linux)
XCode 10 (macOS)
GCC 10 (Solaris)
Visual Studio 2019 Update 4 (Windows)
In particular, on Solaris, GCC is now the only supported compiler. The code has been cleaned up to remove adaptations and workarounds for Sun Studio, Oracle Studio, and SunPro. (Bug #32907274, Bug #103757, Bug #32907475, Bug #32992125, Bug #32992242, Bug #33004840, Bug #33086882)
Oracle, really? What are you doing? How do you plan to support Solaris at least until 2034 without MySQL (and Java)? How should your users run state-of-the-art and patched web applications?
Kind regards,
Steffen
-
Thanks for all that Steffen, you appear to have confirmed that x86 is dropping off the radar (not for the first time in its life).
I presume illumos and smartos will have the same issues.
-
At least in the OpenIndiana repositories, there doesn't seem to be MySQL at all:
https://github.com/OpenIndiana/oi-userland/tree/oi/hipster/components/database
They seem to rely on PostgreSQL and MariaDB (instead of MySQL). For this reason, we (internally at Ulm University) are currently evaluating whether switching from MySQL to MariaDB should be the way to go. My plan is to provide the packages we build to http://sfe.opencsw.org/localhosts12/en/index.shtml.
-
I'll keep an eye on progress and start looking at converting my nextcloud to MariaDB.
Thanks for your efforts.
-
We will move our teaching from MySQL and guess towards Microsoft SQL Server and then we will be ready for when Oracle drops Oracle DB for Solaris. Microsoft products are near enough free for Universities...
Sad days....
-
x86 architecture could get outdated and obsolete because of the power consumption and RAM limit.
-
So, you are dropping all intel chip versions soon then?
If oracle are dropping Solaris compilations of software, then they need to pull up their girl pants and just say it.
Fannying about with silent drops does themselves no credit whatsoever.
They have few enough friends or clients that actually like them as it is.
-
Actually, when comparing the largest SPARC M8-8 servers to the largest x86 X8-8 servers offered by Oracle, I don't see this huge difference in the maximum supported RAM. Oracle's largest x86 servers (which are optional, by the way, still being sold together with Solaris!) support up to 6 TB, their biggest SPARC machines up to 8 TB. So I don't think that this is the main reason for having dropped support for a platform/OS combination while supporting the other one.
When it comes to power consumption, I don't have a comparison of large applications for x86 vs SPARC. If it really was about power efficiency, should we not have seen any Solaris for ARM coming up? ;-)
Kind regards,
Steffen