Re: [OpenIndiana-discuss] When this misery end?
I don't want to reply this at all because I know we will stick with own opinions. But, no, this is not just my definition. This is anyone's definition, Linux, BSDs,... all of them. On Mon, 11 Jan 2021 02:39:17 +0700 Aurélien Larcher wrote > On Sun, Jan 10, 2021 at 8:30 PM Hung Nguyen Gia via openindiana-discuss < > openindiana-discuss@openindiana.org> wrote: > > No, but this is your definition :) > ___ openindiana-discuss mailing list openindiana-discuss@openindiana.org https://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] When this misery end?
On Sun, Jan 10, 2021 at 8:30 PM Hung Nguyen Gia via openindiana-discuss <
openindiana-discuss@openindiana.org> wrote:
> Too many people replied me. I can't answer each of them. This is an AIO
> answer of mine.
>
> First: No, the kernel alone is not enough for you to be a 64 bit ready OS.
> You can only be a 64 bit ready OS when you are 64 bit only. 32 bit lib
> shipped with the system for compatibility is fine. It's what a typical
> multi-lib multi-arch system works. But all of the binaries, must be 64 bit
> only. The compiler, should or should not, be a multi-lib multi-target
> supported compiler, that allowing cross compile to the 32 bit target.
>
> Do you think you really meet this definition?
>
No, but this is your definition :)
>
> Second: Enterprise OS and compatibility
>
> Switching all of the binaries to be 64 bit only doesn't effect
> compatibility at all. Targeting 64 bit binaries doesn't effect
> compatibility at all. As long as you still support running 32 bit apps and
> ship with 32 bit lib to enable those apps to run. Unless, your apps have a
> hard requirement that some tools must be 32 bit otherwise it will not work?
> I don't know anything like that exists.
>
> Third: Create a package?
>
> Got it. You have to use complicated scripts to mitigate Sun's bad decision
> in the past, when they are not transitioned completely to a 64 bit system.
> Or not yet? Sun had to stop before it has any chance. Oracle acquired it.
>
> Now I know why you have too few apps. Software developers prefer the plain
> old ./configure make make install you just said is the past. It plain and
> simple way allows them to have a glimpse if their software would build and
> run on your OS or not. Remember, you are not the primary platform.
> Nowadays, it's Linux. Requiring them to setup a whole system like a real OI
> developer just to be able to correctly compile their software? Forget it,
> your OS grey-listed. Not worth the effort!
>
> The idea of setting up a whole system like that also ill formed. I think
> the FreeBSD Ports get it more correct. The software must be able to build
> and run fine on the porter's computer first. Only after that, he created a
> port (make files) and submit it to the project to get it build and ready to
> be installed for the users. You did the completely reverse thing.
>
> Fourth: Sun's approach made more sense?
>
> Nope. When everyone in the world switch to eat potatoes, if you continue
> to eat bread people will call you crazy. All of the other OSes, not
> mentioning Linux, the BSDs, all following Linux's convention, let alone
> it's a big if if Sun's approach really made any more sense at all.
>
> But you have to keep it to keep compatibility. It's understandable, for an
> enterprise system.
>
> But, you could change anything that doesn't break compatibility, don't
> you? Let's make the life of all of us more easier.
>
> Fifth: I know the problem is ld incorrectly link my 64 bit objects with a
> 32 bit crt. But how can I stop it from happening?
>
> It's your linker's fault, not me. It could be a limitation, or even bug. I
> correctly have all of my objects being 64 bit, but it still incorrectly
> link them with a 32 bit crt.
>
> Which flags I needed to specify? LD='ld -64' or LD='ld -m64'? Nope. Not
> work. Even hacked the meson.build file to add these 64 flags doesn't have
> any affects.
>
> Why it's too complicated and annoying on your OS? On Linux, or the BSDs, I
> could simply doing everything the old way straight forward.
>
> BTW, if the full oi-userland thingy is the only way to get everything
> correctly, I think I would give it a try. Not promise, though.
>
> I was cut off from my friend's PC and now on my old 4 cores 8 GB RAM PC.
>
> OpenIndiana eats resources like hell. Even when limiting the ZFS ARC Cache
> size.
>
> Someone on this lists did said me to just dd my efi partition of OI on my
> external SSD to the USB stick? Well, this destroyed my friend's Windows 10
> boot loader. Good job, Mr. Hacker. Good job.
>
>
> On Mon, 11 Jan 2021 01:45:35 +0700 Aurélien Larcher <
> aurelien.larc...@gmail.com> wrote
>
> > On Sun, Jan 10, 2021 at 6:55 AM Hung Nguyen Gia via openindiana-discuss
> <
> > openindiana-discuss@openindiana.org> wrote:
> >
> > > Unlike other systems, Illumos is a weirded platform! You have a 64
> bit OS
> > > but the compiler by default will generate 32 bit binaries! The linker
> by
> > > default link 32 bit binaries! This has caused endless of troubles for
> > > people wanted to have their software working on your platform and the
> > > porters wanted to port software to your platform! I have asked many
> people,
> > > apart from the reason you are being a minor platform ('outdated',
> 'dead
> > > OS', 'too little market share',...) this insanity is the second
> reason why
> > > they all afraid!
> > >
> >
> > The reason is simple, historically the compiler and toolchain would
> default
> > to the least common denominator.
> >
>
Re: [OpenIndiana-discuss] When this misery end?
The linker generates output of the same form as its input (32 or 64bit, x86 or sparc). Anything happening other than that is happening through the compiler front end. ___ openindiana-discuss mailing list openindiana-discuss@openindiana.org https://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] When this misery end?
Too many people replied me. I can't answer each of them. This is an AIO answer
of mine.
First: No, the kernel alone is not enough for you to be a 64 bit ready OS. You
can only be a 64 bit ready OS when you are 64 bit only. 32 bit lib shipped with
the system for compatibility is fine. It's what a typical multi-lib multi-arch
system works. But all of the binaries, must be 64 bit only. The compiler,
should or should not, be a multi-lib multi-target supported compiler, that
allowing cross compile to the 32 bit target.
Do you think you really meet this definition?
Second: Enterprise OS and compatibility
Switching all of the binaries to be 64 bit only doesn't effect compatibility at
all. Targeting 64 bit binaries doesn't effect compatibility at all. As long as
you still support running 32 bit apps and ship with 32 bit lib to enable those
apps to run. Unless, your apps have a hard requirement that some tools must be
32 bit otherwise it will not work? I don't know anything like that exists.
Third: Create a package?
Got it. You have to use complicated scripts to mitigate Sun's bad decision in
the past, when they are not transitioned completely to a 64 bit system. Or not
yet? Sun had to stop before it has any chance. Oracle acquired it.
Now I know why you have too few apps. Software developers prefer the plain old
./configure make make install you just said is the past. It plain and simple
way allows them to have a glimpse if their software would build and run on your
OS or not. Remember, you are not the primary platform. Nowadays, it's Linux.
Requiring them to setup a whole system like a real OI developer just to be able
to correctly compile their software? Forget it, your OS grey-listed. Not worth
the effort!
The idea of setting up a whole system like that also ill formed. I think the
FreeBSD Ports get it more correct. The software must be able to build and run
fine on the porter's computer first. Only after that, he created a port (make
files) and submit it to the project to get it build and ready to be installed
for the users. You did the completely reverse thing.
Fourth: Sun's approach made more sense?
Nope. When everyone in the world switch to eat potatoes, if you continue to eat
bread people will call you crazy. All of the other OSes, not mentioning Linux,
the BSDs, all following Linux's convention, let alone it's a big if if Sun's
approach really made any more sense at all.
But you have to keep it to keep compatibility. It's understandable, for an
enterprise system.
But, you could change anything that doesn't break compatibility, don't you?
Let's make the life of all of us more easier.
Fifth: I know the problem is ld incorrectly link my 64 bit objects with a 32
bit crt. But how can I stop it from happening?
It's your linker's fault, not me. It could be a limitation, or even bug. I
correctly have all of my objects being 64 bit, but it still incorrectly link
them with a 32 bit crt.
Which flags I needed to specify? LD='ld -64' or LD='ld -m64'? Nope. Not work.
Even hacked the meson.build file to add these 64 flags doesn't have any affects.
Why it's too complicated and annoying on your OS? On Linux, or the BSDs, I
could simply doing everything the old way straight forward.
BTW, if the full oi-userland thingy is the only way to get everything
correctly, I think I would give it a try. Not promise, though.
I was cut off from my friend's PC and now on my old 4 cores 8 GB RAM PC.
OpenIndiana eats resources like hell. Even when limiting the ZFS ARC Cache size.
Someone on this lists did said me to just dd my efi partition of OI on my
external SSD to the USB stick? Well, this destroyed my friend's Windows 10 boot
loader. Good job, Mr. Hacker. Good job.
On Mon, 11 Jan 2021 01:45:35 +0700 Aurélien Larcher
wrote
> On Sun, Jan 10, 2021 at 6:55 AM Hung Nguyen Gia via openindiana-discuss <
> openindiana-discuss@openindiana.org> wrote:
>
> > Unlike other systems, Illumos is a weirded platform! You have a 64 bit OS
> > but the compiler by default will generate 32 bit binaries! The linker by
> > default link 32 bit binaries! This has caused endless of troubles for
> > people wanted to have their software working on your platform and the
> > porters wanted to port software to your platform! I have asked many
> > people,
> > apart from the reason you are being a minor platform ('outdated', 'dead
> > OS', 'too little market share',...) this insanity is the second reason why
> > they all afraid!
> >
>
> The reason is simple, historically the compiler and toolchain would default
> to the least common denominator.
>
> In this case there was not really a question of right or wrong but a matter
> of convention.
> Solaris defines an Instruction Set Architecture (ISA) which may be
> supplemented with processor-specific extensions.
> In our case the architecture is i386 and amd64 is seen as an extension.
> The toolchain
Re: [OpenIndiana-discuss] When this misery end?
On Sun, 10 Jan 2021, Hung Nguyen Gia wrote: Illumos is not 64 bit ready. This is why the compiler has to target 32 bit by default. All Illumos distros have this limitation. It has been 64-bit ready since 1995. At the time (and even now), most apps did not benefit from 64-bit, although they consumed more memory and disk space. It was only when AMD introduced its AMD64 architecture that apps not requiring a huge data-set might benefit from 64-bit. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt ___ openindiana-discuss mailing list openindiana-discuss@openindiana.org https://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] When this misery end?
On Sun, Jan 10, 2021 at 6:55 AM Hung Nguyen Gia via openindiana-discuss <
openindiana-discuss@openindiana.org> wrote:
> Unlike other systems, Illumos is a weirded platform! You have a 64 bit OS
> but the compiler by default will generate 32 bit binaries! The linker by
> default link 32 bit binaries! This has caused endless of troubles for
> people wanted to have their software working on your platform and the
> porters wanted to port software to your platform! I have asked many people,
> apart from the reason you are being a minor platform ('outdated', 'dead
> OS', 'too little market share',...) this insanity is the second reason why
> they all afraid!
>
The reason is simple, historically the compiler and toolchain would default
to the least common denominator.
In this case there was not really a question of right or wrong but a matter
of convention.
Solaris defines an Instruction Set Architecture (ISA) which may be
supplemented with processor-specific extensions.
In our case the architecture is i386 and amd64 is seen as an extension.
The toolchain for a given ISA would therefore default to 32-bit (the least
common denominator) or use extensions if instructed to do so with flags.
This has been the convention for Solaris on sparc and i386.
Alan would be able to explain this better than I do.
This was also an approach chosen on at least some IRIX versions where some
workstations with MIPS R10K and dedicated ASICS would use optimized
binaries with such support.
The path chosen by most Linux distributions was to consider amd64 (later
renamed x86_64) as a different architecture and therefore distribution pure
64-bit.
However Debian for instance discovered rather soon that they had to provide
32-bit libraries for compatibility and retrofitted the "lib32" libraries,
and later on delivered libraries in subdirectories based on the platform
triplet.
So IMHO the Solaris approach made more sense, since you had to specify
which ISA and which standard compliance were intended.
On the contrary Linux distributions relied often on defaults guided by
convenience and selecting the "standard of the day", this has changed a lot
in recent years.
However, one could argue that 32-bit is not relevant anymore and that the
least common denominator should be replaced by the actual intended
architecture: 64-bit in this case.
Therefore I took the liberty of selecting 64-bit code generation by default
since I packaged gcc-9, and kept the same rule for gcc-10.
So your complaint is not founded at all: we are transitioning as fast as
time permits.
Some of the issues with the migration to gcc-10 was indeed the assumption
the build system made on the defaut bitness of generated binaries.
I fixed about a hundred of such issues back in spring last year.
Most of your issues come from incorrect assumptions: this is often the case
when you are used to one type of system and some of the problems you
mention denote a lack of experience with UNIX in a broad sense.
I had the same expectation when I started my Linux/UNIX journey 15 years
ago as a student in engineering.
However I was very curious and willing to learn the differences between
systems so I installed and played with Debian, OpenBSD, NetBSD, FreeBSD,
Solaris 7/8/9/10, IRIX, on various machines including SPARC and Alpha
workstations.
Talking and throwing anathema is not really something I am interested in.
I'd rather work on contributing and take a constructive approach.
I was a member of a Linux user group from 2003 to 2008 where BSD/Solaris
users were often mocked for using inferior systems: I was once called an
idiot for installing NetBSD and Solaris on my machines.
Interestingly whenever the discussion became a bit technical and concrete
about what they did not like about BSD/Solaris/IRIX most Linux proselytes
in the group would actually admit that they had never run anything else
than Debian or Red Hat :)
The Slackware guru in the group always sided with BSD people though :P
We would eventually reconcile around a few bottles of beer and a few pizzas
:D
In any case, as other people mentioned we have a build system to set all
the flags automatically if you are not familiar with UNIX.
If you choose to compile things outside this environment then you need some
minimal knowledge of the environment.
These things, while they could be made more convenient, are luckily fairly
trivial and most of us deal with them.
We talked about this some months ago and unfortunately I got sick and could
not do the gcc-10 migration.
So here we are again with you complaining :P :P :P
Cheers
Aurelien
> When would we could be as normal as other 64 bit system, when people no
> longer have to pass CC='gcc -m64' CXX='g++ -m64' before any configure
> scripts with a very high rate of failure just to have 64 bit binaries
> generated, I wonder?
>
> ___
> openindiana-discuss mailing list
> openindiana-discuss@openindiana.org
>
Re: [OpenIndiana-discuss] When this misery end?
Am 10.01.21 um 17:14 schrieb Hung Nguyen Gia via openindiana-discuss: Illumos is not 64 bit ready. This is why the compiler has to target 32 bit by default. All Illumos distros have this limitation. Don't get me wrong, I have read that many parts of the OS itself remain to be 32 bit, e.g: nscd, they are not yet 64 bit ready. I pretty much agreed and appreciate the Unleashed OS initiative but sadly it was terminated: https://unleashed-os.org/ It is, IMHO, what Illumos should be. But you are partially right, though. Nothing stop we from setup the compiler to provide 64 bit binaries by default but still keeps the -m32 target so we could build the not 64 bit ready parts of the OS, too. This, indeed, is what many Linux distros are doing now. We are really weirded, because we are a 64 bit OS but choose to 'cross compile' to 32 bit by default. It should be the otherwise around: a 64 bit OS which generates 64 bit binaries by default but offer to 'cross compile' to 32 bit. But all of the Illumos distros did so, not only us. It's the general limitation of the platform. Put all of this aside, I only want to know how to fix my current linking issue with libdazzle. I have no idea to workaround this 'Wrong ELF Class' issue. This error happens when you try to combine 64-bit and 32-bit object files (or libraries). As I already wrote: I have a complete package description for libdazzle on OI Hipster. I can send it to you if you want (and give me the address to send to). I can even create a package from it for and provide it in p5p format so you can install it on your system. It provides both, 32 and 64 bit versions. But that will only be a single step on your way to provide/create a working epiphany. You'll probably need to create or update other packages, too. And that's also the reason to create packages: you can keep things separate and have version tags. So you can update them inidividually. ___ openindiana-discuss mailing list openindiana-discuss@openindiana.org https://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] When this misery end?
On Sunday, January 10, 2021, 6:14:49 PM GMT+2, Hung Nguyen Gia via openindiana-discuss wrote: >Illumos is not 64 bit ready. This is why the compiler has to target 32 bit by >default. All Illumos >distros have this limitation. The kernel in my system is a 64bit binary. This means the system is a 64bit system. >Don't get me wrong, I have read that many parts of the OS itself remain to be >32 bit, >e.g: nscd, they are not yet 64 bit ready. Older versions of various Linux distros were the same: they provided bith 32bit and 64bit binaries for reasons of compatibility. Now they only provide 64bit binaries. Illumos-based systems still provide both 32bit and 64bit binaries. I read somewhere that Solaris 11 does not supply 32bit binaries anymore. Maybe in the future, the people who are packaging OI will do the same. A.S. -- Apostolos Syropoulos Xanthi, Greece ___ openindiana-discuss mailing list openindiana-discuss@openindiana.org https://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] When this misery end?
Illumos is not 64 bit ready. This is why the compiler has to target 32 bit by default. All Illumos distros have this limitation. Don't get me wrong, I have read that many parts of the OS itself remain to be 32 bit, e.g: nscd, they are not yet 64 bit ready. I pretty much agreed and appreciate the Unleashed OS initiative but sadly it was terminated: https://unleashed-os.org/ It is, IMHO, what Illumos should be. But you are partially right, though. Nothing stop we from setup the compiler to provide 64 bit binaries by default but still keeps the -m32 target so we could build the not 64 bit ready parts of the OS, too. This, indeed, is what many Linux distros are doing now. We are really weirded, because we are a 64 bit OS but choose to 'cross compile' to 32 bit by default. It should be the otherwise around: a 64 bit OS which generates 64 bit binaries by default but offer to 'cross compile' to 32 bit. But all of the Illumos distros did so, not only us. It's the general limitation of the platform. Put all of this aside, I only want to know how to fix my current linking issue with libdazzle. I have no idea to workaround this 'Wrong ELF Class' issue. This issue is a known problem: https://blogs.oracle.com/solaris/wrong-elf-class-requires-consistent-compiler-flags-v2 It have haunted many developers and scared them from even attempt to make their software compile on Solaris/Illumos. On Sun, 10 Jan 2021 22:00:51 +0700 Bob Friesenhahn wrote > On Sun, 10 Jan 2021, Hung Nguyen Gia via openindiana-discuss wrote: > > > Unlike other systems, Illumos is a weirded platform! You have a 64 > > bit OS but the compiler by default will generate 32 bit binaries! > > The linker by default link 32 bit binaries! This has caused endless > > This is not a feature of Illumos, rather it is a feature of the > compiler delivered by the distribution. > > There are compilers targeting Illumos which produce 64-bit output by > default. > > There is nothing actually wrong with 32-bit apps since they can > safely address 2GB of memory, which is quite a lot. The 64-bit ABI > does provide more registers and instructions and improved calling > convention so code may run faster. > > Bob > -- > Bob Friesenhahn > bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ > GraphicsMagick Maintainer, http://www.GraphicsMagick.org/ > Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt > > ___ > openindiana-discuss mailing list > openindiana-discuss@openindiana.org > https://openindiana.org/mailman/listinfo/openindiana-discuss > ___ openindiana-discuss mailing list openindiana-discuss@openindiana.org https://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] When this misery end?
You misunderstood what we tried to tell you:
http://docs.openindiana.org/dev/userland/ is not only a description on
how to be able to contribute to oi-userland but also a receipt for
building complex software
which epiphany is an example for.
The machinery behind oi-userland is exactly there to minimize the work
on building software for OI Hipster. That you will be able to
participate on the
development of OI userland is just a side effect. Creating a package
suitable for an OS is also the standard. The times of locally running
"make install" are long gone,
except for those distribution where it is explicitly part of the base ideas.
Especially for a common library like libdazzle it is not uncommon to
have both, 32-bit and 64-bit versions, in order to provide them for who
and whatever needs it.
The OI Hipster is 64-bit only but that doesn't mean that all executables
are 64-bit, too. On the contrary we have some apps that are still 32-bit
only, eg. libreoffice.
Just because you don't understand a complex system at a glance doesn't
mean that it is "weird". It just tells you that you have to learn more.
You would have similar
problems on other OS's, too, especially when you try to work against
what is intended to support you in your work.
Andreas
Am 10.01.21 um 13:39 schrieb Hung Nguyen Gia:
I appreciate your help. BTW, your link, has nothing to do with what I'm
currently trying to do. Maybe it would be useful when I could have Epiphany
compiled for me and started to get it packaged on OI.
What I do now is very simple: trying to build software from source. I'm not yet
on the state of able to contribute it. I currently doesn't build.
I make one correction: none of Epiphany or libdazzle requires gcc-10. It was
me, confused, and out of idea why it failed, tried to see if it would compile
with the latest GCC version. It turns out it still fails to build on gcc-10,
commenting out a compiler flag on meson.build did the trick. The current
trouble is no longer compilation, but linking.
Not everything Sun did was right. This 'Wrong ELF Class' issue was haunted many
people for a long long time. Doing a simple search with 'Solaris ld wrong elf
class' will give you more than enough evidences.
From what I have read here:
https://blogs.oracle.com/solaris/wrong-elf-class-requires-consistent-compiler-flags-v2
Only the OI developers could handle the problem. I can do NOTHING other than
waiting for them having an up and working libdazzle from the OI repo so I could
just install it using pkg and continue with Epiphany.
Maybe we could have a look at Linux or FreeBSD to know how to design a proper
multi-lib system?
We are not the only multi-lib system out there. Debian Linux and FreeBSD is an
out of the box multi-lib system, but, they don't have such problem. I don't see
any of their users whining about something similar than this one. Maybe we
could learn something from them?
I know, we inherits the legacy from Solaris. We are currently stuck with the
Solaris linker. Binaries produced by the GNU ld linker is incompatible. So I'm
very patient and waiting for the help from the OI devs.
I hope someday Illumos in general, could get rid of Solaris compatibility and
the Solaris linker, switching to a proper GNU ld linker like other systems. OI
is such a small project so it can only waits for the big players to try first
then upstream their changes to illumos-gate.
On Sun, 10 Jan 2021 17:24:55 +0700 Andreas Wacknitz
wrote
> Am 10.01.21 um 06:55 schrieb Hung Nguyen Gia via openindiana-discuss:
> > Unlike other systems, Illumos is a weirded platform! You have a 64 bit OS
but the compiler by default will generate 32 bit binaries! The linker by default link
32 bit binaries! This has caused endless of troubles for people wanted to have their
software working on your platform and the porters wanted to port software to your
platform! I have asked many people, apart from the reason you are being a minor
platform ('outdated', 'dead OS', 'too little market share',...) this insanity is the
second reason why they all afraid!
> >
> > When would we could be as normal as other 64 bit system, when people no
longer have to pass CC='gcc -m64' CXX='g++ -m64' before any configure scripts with a
very high rate of failure just to have 64 bit binaries generated, I wonder?
> >
> > ___
> > openindiana-discuss mailing list
> > openindiana-discuss@openindiana.org
> > https://openindiana.org/mailman/listinfo/openindiana-discuss
> Hi,
>
> you have already been told that you should read
> http://docs.openindiana.org/dev/userland/
> and make use of what is already available. You don't need to start from
> scratch but can use
> what Sun has originally created, and Oracle for Solaris 11 and the OI
> team for OpenIndiana enhanced.
> You seem to want to take a shortpath but that won't work. Building
> software like epiphany is
Re: [OpenIndiana-discuss] When this misery end?
On Sun, 10 Jan 2021, Hung Nguyen Gia via openindiana-discuss wrote: Unlike other systems, Illumos is a weirded platform! You have a 64 bit OS but the compiler by default will generate 32 bit binaries! The linker by default link 32 bit binaries! This has caused endless This is not a feature of Illumos, rather it is a feature of the compiler delivered by the distribution. There are compilers targeting Illumos which produce 64-bit output by default. There is nothing actually wrong with 32-bit apps since they can safely address 2GB of memory, which is quite a lot. The 64-bit ABI does provide more registers and instructions and improved calling convention so code may run faster. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt ___ openindiana-discuss mailing list openindiana-discuss@openindiana.org https://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] When this misery end?
I appreciate your help. BTW, your link, has nothing to do with what I'm
currently trying to do. Maybe it would be useful when I could have Epiphany
compiled for me and started to get it packaged on OI.
What I do now is very simple: trying to build software from source. I'm not yet
on the state of able to contribute it. I currently doesn't build.
I make one correction: none of Epiphany or libdazzle requires gcc-10. It was
me, confused, and out of idea why it failed, tried to see if it would compile
with the latest GCC version. It turns out it still fails to build on gcc-10,
commenting out a compiler flag on meson.build did the trick. The current
trouble is no longer compilation, but linking.
Not everything Sun did was right. This 'Wrong ELF Class' issue was haunted many
people for a long long time. Doing a simple search with 'Solaris ld wrong elf
class' will give you more than enough evidences.
From what I have read here:
https://blogs.oracle.com/solaris/wrong-elf-class-requires-consistent-compiler-flags-v2
Only the OI developers could handle the problem. I can do NOTHING other than
waiting for them having an up and working libdazzle from the OI repo so I could
just install it using pkg and continue with Epiphany.
Maybe we could have a look at Linux or FreeBSD to know how to design a proper
multi-lib system?
We are not the only multi-lib system out there. Debian Linux and FreeBSD is an
out of the box multi-lib system, but, they don't have such problem. I don't see
any of their users whining about something similar than this one. Maybe we
could learn something from them?
I know, we inherits the legacy from Solaris. We are currently stuck with the
Solaris linker. Binaries produced by the GNU ld linker is incompatible. So I'm
very patient and waiting for the help from the OI devs.
I hope someday Illumos in general, could get rid of Solaris compatibility and
the Solaris linker, switching to a proper GNU ld linker like other systems. OI
is such a small project so it can only waits for the big players to try first
then upstream their changes to illumos-gate.
On Sun, 10 Jan 2021 17:24:55 +0700 Andreas Wacknitz
wrote
> Am 10.01.21 um 06:55 schrieb Hung Nguyen Gia via openindiana-discuss:
> > Unlike other systems, Illumos is a weirded platform! You have a 64 bit OS
> > but the compiler by default will generate 32 bit binaries! The linker by
> > default link 32 bit binaries! This has caused endless of troubles for
> > people wanted to have their software working on your platform and the
> > porters wanted to port software to your platform! I have asked many
> > people, apart from the reason you are being a minor platform ('outdated',
> > 'dead OS', 'too little market share',...) this insanity is the second
> > reason why they all afraid!
> >
> > When would we could be as normal as other 64 bit system, when people no
> > longer have to pass CC='gcc -m64' CXX='g++ -m64' before any configure
> > scripts with a very high rate of failure just to have 64 bit binaries
> > generated, I wonder?
> >
> > ___
> > openindiana-discuss mailing list
> > openindiana-discuss@openindiana.org
> > https://openindiana.org/mailman/listinfo/openindiana-discuss
> Hi,
>
> you have already been told that you should read
> http://docs.openindiana.org/dev/userland/
> and make use of what is already available. You don't need to start from
> scratch but can use
> what Sun has originally created, and Oracle for Solaris 11 and the OI
> team for OpenIndiana enhanced.
> You seem to want to take a shortpath but that won't work. Building
> software like epiphany is complex
> on any OS. libdazzle is just a step on your path of a working epiphany
> browser on OI and I guess it's
> one of the more simpler ones. We should do that in a team.
> I have prepared a package description of libdazzle for OI Hipster.
> I am reluctant to add the new library to our repository as it doesn't
> have a consumer in our userland yet
> and I am not sure whether we will need it in the future (eg. if we don't
> agree on adding epiphany in the future).
>
> Furthermore, as it depends on gcc-10 ant its runtime we should
> coordinate this with Aurélien work on
> changing the default compiler for oi-userland to gcc-10. We should
> discuss how to proceed.
>
> If you want it I can send you the sources I generated (based on the
> solaris-userland files). Our build
> system has diverted from Oracle's a bit so some changes have been necessary.
>
> Regards,
> Andreas
>
>
>
> ___
> openindiana-discuss mailing list
> openindiana-discuss@openindiana.org
> https://openindiana.org/mailman/listinfo/openindiana-discuss
>
___
openindiana-discuss mailing list
openindiana-discuss@openindiana.org
Re: [OpenIndiana-discuss] When this misery end?
Am 10.01.21 um 06:55 schrieb Hung Nguyen Gia via openindiana-discuss:
Unlike other systems, Illumos is a weirded platform! You have a 64 bit OS but
the compiler by default will generate 32 bit binaries! The linker by default
link 32 bit binaries! This has caused endless of troubles for people wanted to
have their software working on your platform and the porters wanted to port
software to your platform! I have asked many people, apart from the reason you
are being a minor platform ('outdated', 'dead OS', 'too little market
share',...) this insanity is the second reason why they all afraid!
When would we could be as normal as other 64 bit system, when people no longer
have to pass CC='gcc -m64' CXX='g++ -m64' before any configure scripts with a
very high rate of failure just to have 64 bit binaries generated, I wonder?
___
openindiana-discuss mailing list
openindiana-discuss@openindiana.org
https://openindiana.org/mailman/listinfo/openindiana-discuss
Hi,
you have already been told that you should read
http://docs.openindiana.org/dev/userland/
and make use of what is already available. You don't need to start from
scratch but can use
what Sun has originally created, and Oracle for Solaris 11 and the OI
team for OpenIndiana enhanced.
You seem to want to take a shortpath but that won't work. Building
software like epiphany is complex
on any OS. libdazzle is just a step on your path of a working epiphany
browser on OI and I guess it's
one of the more simpler ones. We should do that in a team.
I have prepared a package description of libdazzle for OI Hipster.
I am reluctant to add the new library to our repository as it doesn't
have a consumer in our userland yet
and I am not sure whether we will need it in the future (eg. if we don't
agree on adding epiphany in the future).
Furthermore, as it depends on gcc-10 ant its runtime we should
coordinate this with Aurélien work on
changing the default compiler for oi-userland to gcc-10. We should
discuss how to proceed.
If you want it I can send you the sources I generated (based on the
solaris-userland files). Our build
system has diverted from Oracle's a bit so some changes have been necessary.
Regards,
Andreas
___
openindiana-discuss mailing list
openindiana-discuss@openindiana.org
https://openindiana.org/mailman/listinfo/openindiana-discuss
[OpenIndiana-discuss] When this misery end?
Unlike other systems, Illumos is a weirded platform! You have a 64 bit OS but
the compiler by default will generate 32 bit binaries! The linker by default
link 32 bit binaries! This has caused endless of troubles for people wanted to
have their software working on your platform and the porters wanted to port
software to your platform! I have asked many people, apart from the reason you
are being a minor platform ('outdated', 'dead OS', 'too little market
share',...) this insanity is the second reason why they all afraid!
When would we could be as normal as other 64 bit system, when people no longer
have to pass CC='gcc -m64' CXX='g++ -m64' before any configure scripts with a
very high rate of failure just to have 64 bit binaries generated, I wonder?
___
openindiana-discuss mailing list
openindiana-discuss@openindiana.org
https://openindiana.org/mailman/listinfo/openindiana-discuss
