[for steam] MultiLib.TCZ !!! !!! ( no need to create a new TCZ file package )

[xor]

[for steam] MultiLib.TCZ !!!
no need to create a new TCZ file package,
everything is already in repository

TCL can be a minimalist linux! but big needs never get smaller.
even if a game is 100 GB; workspace is limited by RAM space.

I do not want to get into the discussion of different opinions.
The solution and what it takes to progress is very simple.
please do not ignore realistic needs

The linux standards are still seriously not settled for a long time!
Even Windows applications are a more stable and long-term working layer in this respect.

linux has always existed as a kernel
this is the basic philosophy of linux anyway.

[andyj]

Multilib requires that every library have a multilib version. For Slackware multilib (Slackware is NOT multilib as shipped, someone else maintains the multilib library versions) that 215 libraries the last time I installed it. I don't see that happening here, unless YOU are going to take that on. It would be nice that instead of being an extension request bot you began to contribute.

[xor]

I am not experienced in creating extensions,
my logic is that this would not be the "MultiLib.TCZ" file; I assume it will be a context extension caller, literally a "MultiLib.dep" file.

now; How can I create a "MultiLib" library for TCL!?
Could you please help me with this.
If you describe it step by step, I'll try to do my best.

Multilib requires that every library have a multilib version. For Slackware multilib (Slackware is NOT multilib as shipped, someone else maintains the multilib library versions) that 215 libraries the last time I installed it. I don't see that happening here, unless YOU are going to take that on. It would be nice that instead of being an extension request bot you began to contribute.

[Juanito]

See here: http://www.linuxfromscratch.org/~dj/lfs-systemd-multilib/chapter10/chapter10.html

[xor]

logical inference ;;;
I am using TCL 64 and there is already a 64-bit library in the system.
If I also use TCL 32; it contains; adds the missing 32-bit library to the system.
How can I combine these 2 libraries in a simple way!?
Please suggest an easier and simpler way.

You already have the entire library in your download archive!

[Juanito]

This is the easiest and simplest method I have seen.

You cannot combine 64-bit and 32-bit libraries in the same directory as they have identical names - this is why the lfs link I gave chooses to use /lib for 64-bit libraries and /lib32 for 32-bit libraries.

I suggest that you follow the instructions and see if it works.

[xor]

from Google Translate ; As far as I understand from the resulting translations

TCL11 x86_64-bit >> / lib /
places 64-bit contents into the system with the directory name
TCL11 x86_32-bit >> / lib /
places 32-bit contents into the system with the directory name

After the content compilation on the page you recommend
file call addresses are being changed. ( I understand that )

TCL11 places 64-bit contents into the system with the name x86_64-bit >> / lib64 / directory
TCL11 places 32-bit contents into the system with the name x86_32-bit >> / lib32 / directory

then from the TCL development commission and committee
my request is packaging from now on
general / lib / not generalizing from under the name!

If you create a TCL12 x86_64-bit >> / lib64 / configuration
If you create a TCL12 x86_32-bit >> / lib32 / configuration
system integration makes more sense for everyone.

if you don't do this; MultiLib can never be added to TCL in a healthy way!

[Juanito]

32-bit tinycorelinux is a standalone release, hence it makes sense to use /lib.
64-bit tinycorelinux is a standalone release, hence it makes sense to use /lib.

If somebody decides to create a multi-lib tinycorelinux, they are welcome to choose which lib name to use.

[xor]

I know there are different and independent things
but uses the same names under the same folder name
No need to rename them all!
Simply differentiating the folder literally might solve the problem.
(Lib64 can preserve its authenticity by using Lib32 names)
Of course, it is important to compile the calls to the folder.

please It is very important to concentrate on a method that can be a solution instead of defending a mistake.

For this ; May be a good new start in TCL 12 version

My suggestion to configure my new system for TCL! I will suggest configuring the folder names to be named 32 and 64 bits.

recommendation content picture;



It is important to use the original bit name
128-bit processor in the near future
and with it Lib128
or quantum processor & bit
Possible library compilations in LibQB form are also possible!

[Juanito]

As mention in the url I gave, the instructions are to add multi-lib to an existing system - i.e. CorePure64.

Once you've compiled the simple multi-lib environment and reported back, we'll know where we stand...

[xor]

google translate could not interpret this line correctly!

Once you've compiled the simple multi-lib environment and reported back, we'll know where we stand...

could you please use an alternative expression!?

[Sashank999]

Juanito says that :
1. Compile yourself the binaries and libs needed for multilib
2. Say us if the method worked.

My suggestion :
Just leave the multilib on TCL. If you really need a multilib, get Arch Linux and then disable all the unnecessary stuff. I don't think multilib on TCL is good. PCs with low performance(the targets of TCL) really don't need multilib. If you really want to compile multilib on TCL, it is something that we can't help progress. We can just give the guidance.

And google translate doesn't work always and I know this because I have another mother tongue and English is my second language. This is a proof that machines do mistakes LOL.

[xor]

understood now, but I think this should be adopted as a system update.

Structurally you will need multilib for 64-bit anyway.
(Since 32-bit processor cannot use 64-bit structures)
And for the future, maybe a few years from now, to avoid compilation conflicts with 128 bit-or quantum-bit infrastructure

I just know that TCL12x86_64-bit linux from architectural point of view
As soon as the "+ Lib32" folder content is added, I want it to switch to multilib functionality.

I don't want the content of TCL12x86_64-bit linux to inflate the content of MultiLib literally TCL12.

I think the Lib Folder should be defined as Lib64 in TCL12.
MultiLib.TCZ will optionally download the contents of the Lib32 Folder as content (MultiLib.dep) from the already existing Internet repository archive.

If the link content is correct, the result will be positive.
but it will not be different from a personal configuration.

This flexible structure should be adopted in TCL12x86_64-bit linux architecture.

I think the existing TCL fits the minimalist philosophy.

Juanito says that :
1. Compile yourself the binaries and libs needed for multilib
2. Say us if the method worked.

My suggestion :
Just leave the multilib on TCL. If you really need a multilib, get Arch Linux and then disable all the unnecessary stuff. I don't think multilib on TCL is good. PCs with low performance(the targets of TCL) really don't need multilib. If you really want to compile multilib on TCL, it is something that we can't help progress. We can just give the guidance.

And google translate doesn't work always and I know this because I have another mother tongue and English is my second language. This is a proof that machines do mistakes LOL.

[xor]

In TCL12 x86_64-bit architecture, the 64-bit Lib folder structure should be named "Lib64" and optionally

MultiLib32.tcz (TCL12 x86_64-bit) I suggest creating the MultiLib32.dep file content.

In this way, no changes will occur in the existing TCL minimalist file size, and the optional MultiLib content will be added to the system in a minimalist way.

I strongly request that this be submitted to a committee commission vote in a democratic manner.

[xor]

If you create this configuration for TCL12 x86_64-bit without Lib32, you can optionally
MultiLib32.tcz (TCL12 x86_64-bit! Lib32 content can be created with a plug-in package.
Optionally, the multilib can be accessed.

I am not thinking of creating a personalized linux distro.
my thoughts are an idea study on the creation of an improvable linux architecture.

As mention in the url I gave, the instructions are to add multi-lib to an existing system - i.e. CorePure64.

Once you've compiled the simple multi-lib environment and reported back, we'll know where we stand...