[OpenIndiana-discuss] When this misery end?

[Hung Nguyen Gia]

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 <aurelien.larcher at gmail.com> wrote ----

 > On Sun, Jan 10, 2021 at 6:55 AM Hung Nguyen Gia via openindiana-discuss < 
 > openindiana-discuss at 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 at openindiana.org 
 > > https://openindiana.org/mailman/listinfo/openindiana-discuss 
 > > 
 >  
 >  
 > -- 
 > --- 
 > Praise the Caffeine embeddings 
 > _______________________________________________ 
 > openindiana-discuss mailing list 
 > openindiana-discuss at openindiana.org 
 > https://openindiana.org/mailman/listinfo/openindiana-discuss 
 >