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. > > > > 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 > > > https://openindiana.org/mailman/listinfo/openindiana-discuss > > > > > > > > > -- > > --- > > Praise the Caffeine embeddings > > _______________________________________________ > > 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 > -- --- Praise the Caffeine embeddings _______________________________________________ openindiana-discuss mailing list openindiana-discuss@openindiana.org https://openindiana.org/mailman/listinfo/openindiana-discuss