TOPIC:

Hello,
I have installed CT on Ubuntu 20.04.3 LTS. 2 times, the first time it did not install the big IDE, the second time it was ok. I think this was because of the user rights.
Now after the second installation went well, I can't start it.
The desktop icons don't have the picture and I can't start CT from there, even it is ticked already "allow launching".
What I can do about it, anyone has an idea?

Pascallus

Ubuntu 20.04.3 LTS use old GLIBC
My suggestion is to use
The latest Ubuntu 22.4 or LinuxMint 21 from Debian based distributions,
or
Any ArchLinux based distribution, EndeavourOS, Manjaro etc
or
latest Fedora 36

dear colleague, let me translate the answer of a respected moderator...
he says that the concept of "from any platform, to any platform" is obsolete and will henceforth be replaced by "from windows to windows and some compatible platforms". developers on stable Linux platforms are no longer interested in them.

P.S. the latest working version of the studio is 7.6. personally, I still have to use 6.3 because I don't have enough time to fix bugs in a relatively new version, and my clients demand a quality product.

Vlad Wilhelm wrote:

P.S. the latest working version of the studio is 7.6. personally, I still have to use 6.3 because I don't have enough time to fix bugs in a relatively new version, and my clients demand a quality product.

Please can you tell us somethings, about these CT "Bugs" ?
 

Hello.

I dont think there are bugs in CT but I still dont understand why you compiled CodeTyphon app with experimental-unstable libc.so.6

packages.debian.org/search?keywords=libc6

 

Debian, more than others, knows what is stable or not.

Imho, it should be the opposite, use the older stable libc6.so still working.

Sorry but for me it is not possible (and I dont want) to install a other disto only to have a libc experimental-unsafe that will be linked when compiling my applications and that users cannot use if they did not install experimental-unstable libc.s0.6 on their system.

On the other side, if the application was linked with a old stable libc.so.6, it will be usable even for distros with last libc experimental-unsafe because last libc is backward-compatible.
(Or maybe CT uses new methods of experimental-unsafe libc, but I doubt of this because if they are new methods, it will no more be libc.so.6 but libc.so.7 (or .8).)

These are Debian distribution staff
for Linux kernel 5.10,
and Debian it's NOT the Linux...

All new Linux distributions use Linux Kernel > 5.18 with GLIBC> 2.34

When Debian will  start to use Linux Kernel > 5.18 with GLIBC> 2.34 ?
1,2,3,6 years later ?



 

> These are Debian distribution staff for Linux kernel 5.10,

Yes, that is not the problem, you may also compile libc from trunk (but be carefull, you need to recompile all the kernels too).

> and Debian it's NOT the Linux...

Yes but Linux is libc, without it nothing works.
CT is a Pascal project and dont need the brand new clib version.
For example, I can install + use CodeTyphonIns 7.80 from your download site but I cannot upgrade because CodeTyphon app refuse to run with my libc.

>When Debian will  start to use Linux Kernel > 5.18 with GLIBC> 2.34 ?
> 1,2,3,6 years later ?

Yes and what is the problem?
If your CodeTyphon app was compiled with old stable libc, everybody can use it, even people with GLIBC> 2.34.

Anyway, you are the boss, it is only my 0.1 cent.

fredvs wrote:

> These are Debian distribution staff for Linux kernel 5.10,

Yes and what is the problem?
If your CodeTyphon app was compiled with old stable libc, everybody can use it, even people with GLIBC> 2.34.

Anyway, you are the boss, it is only my 0.1 cent.

No no,
if we build CTCenter with OLD libc then will NOT run on new distributions with libc>2.34
libc>2.34 it's NOT compatible with  old version <2.34

Test this:
Build a CT project on Debian 11 and then test this project on latest Fedora 36 or ArchlLnux .


 

I can tell not only about bugs, but also anticipate your answer
you will immediately say that these are problems of the lazarus libraries and the implementation of widgets of various subversions of gtk2 and qt
however, you are delivering a complete product whose functionality suffers due to underlying resource issues. doesn't it make sense to make an lcl revision instead of just copying it?
however, all of the above, in no case, is not a claim! I am grateful for your work and regularly use your product in my work.
if you really need it, I can dig into old projects in search of "crutches" to bypass native glitches.
things to do regularly:
change links to database libraries in sqldb package;
never use the TCoolBar component;
enable conditional compilation when using TTrayIcon, taking into account the target graphics platform;
add your own hotkey processing library for all TStringGrid descendants, since in the basic version it stupidly intercepts all keyboard activity;
I don't remember from which version, but now console applications that use dynamic loading of external libraries are terminated only by killall -5.
in general, I have written more than 2000 lines of code in my base framework to work around many errors in the logic of most components.
I practically do not use sets of components and libraries that are not included in the basic set of fpc and lazarus, so my review will turn out to be completely incomplete
but the summary looks like this: you are really ignoring the big debian platform related sector and aiming to create a hello world app development platform with only blackjack and...
The world of IT is not much different from the world of aviation, it also requires proven and reliable solutions

My friend
First of all, I want to thank you for using CodeTyphon Studio.

Second we can put any patch you want to CT source, after proper LAB tests.

Now,
I use Debian Linux in our LAB for about 15 years, as Primary Linux Distribution,
and before CodeTyphon Studio release.

But things in programming world change very quickly in the last 2-3 year.

It's obvious 2 years in our LAB, that Debian:
-Every 2 year release for NO rolling distribution ?
-Old kernel ? (and this is the reason for OLD GLIBC< 2.34)
-Out-of-date Packages ?

So, in our LAB we start use as Primary Building Linux Distribution Fedora and ArchLinux based distributions.
We use Debian based distributions only for tests.

Guys, we follow the "programming river", we don't have other choice at this time.

 

Personally,
I spent a lot of days to test CT on ALL Linux Distributions,
before Mr Sternas deside to use Fedora in our LAB. 

dear friend!
striving for something new is great, but let's remember that in the world of IT, the situation with old, tested platforms is the norm. I have to maintain multiple systems on platforms ranging from windows 2003 and debian 7 to the latest versions. not because their IT staff is clumsy, but because of corporate rules. suppose I installed ubuntu 22.4, how can i build WORKING programs for older systems?
I now support multiple platforms (starting from Ubuntu 14.04) in virtual machines for debugging and building for the target platform (some libraries REQUIRE a specific build environment, such as FFMPEG ).
I would be very grateful if the new version of the studio will, as before, be built based on the environment and the capabilities of the installed libraries.

> libc>2.34 it's NOT compatible with  old version <2.34

Hum, OK, I trust you (but I did not try yet).
If so, it is a very bad point for libc, it should be backward compatible.

I have read in the past that fpc is working to be independent from libc, do you know when it will be?
 

fredvs wrote:

> libc>2.34 it's NOT compatible with  old version <2.34
 

as minimum, you cannot unload external libraries. this is more than enough...

Trying to find solution for that libc problem.

Maybe using dynlib and LoadLibrary() in place of using "external" to load the library and so no need to link libc at compilation.
But for this, some work must be done for a Pascal header of the libc-methods. (maybe it was already done ?)

[EDIT]
I will try to dynamically load libc for MSEgui (here result of link.res of a MSEgui program)

INPUT(
-l:libc.so  // try to not use this but loadlibrary() instead
-lpthread
-l:libdl.so
-l:libX11.so.6
-l:libpthread.so
-l:librt.so
-lm
)

If there are good results, I will advice, maybe CT could use it too.

Would PilotLogic consider building the CodeTyphon application on user computer from source?
This would solve a part of the problem, but then the CodeTyphon application would no longer
be proprietary and closed source.

@Nino Luciani: No Sir, we will not open CTCenter source.
We can build and provide CTCenter for OLD Linux distributions like Debian 11.

@fredvs: Again your old dynlib story, 
I don't have the LAB man power for this now,
we are only 3 core programmers at our LAB until the end of Aug.

We will follow for this the FreePascal team way.

> @fredvs: Again your old dynlib story, 



I did not note that problems with incompatible sub-version of libc.so.6.
It is very annoying.  Anyway, I will try to use that dynlib story for MSEgui, just for the fun.

And for CTCenter, it would be great to have it compiled with old libc, like you proposed.
( Or maybe add in the install.sh script a option "Upgrade CT with last develop source" )

Anyway, I learn things about libc-new-release policy, thanks for this.

Have fun.

Fre;D




 

Hello Sternas:

> We will follow for this the FreePascal team way.

After big fight I was able to isolate all call to libc.so via "external" (and so disable linking to libc.so) for MSEgui and all his components and use the "old Dynlibs" way.
But MSEgui uses the rtl of fpc and some of the rlt-packages have the linklib c directive, so at the end of the compilation, it links to libc.so because of the rtl.

And change all the rtl for the "old Dynlibs" way is too much work, so ok, I forget this option.
( But I maintain that the policy of libc.so.6 to not be compatible with sub-version is not fair. But this is a other story.)
( Also, that libc.so.6 is a kind of jungle, methods with no logical names, sometime using prefix "__" sometime other prefix without any logical, etc... )

So, to resume, I will also follow the FreePascal way for libc and sorry for the noise.

Fre;D
 

My friend before about 1-2 years we test your suggestion for "dynlib" to all CT Host OSes
and we have a lot of problems.

No problem for the "noise", we are programmers and we must test anything again and again...