Slackware 10.2 + Kernel 2.6.13 = OK, after adding...
Forrest
Before adding that I was getting this error:
libwine.borland.so: symbol errno, version GLIBC_2.0 not defined in file
libc.so.6 with link time reference
Andreas Hausladen
application from the IDE.
--
Regards,
Andreas Hausladen
(http://andy.jgknet.de/blog)
Forrest
> Does the integrated debugger work? Or does it hang if you start an
> application from the IDE.
Oops -- I'd forgotten there *was* a debugger.[1] [Pause to check] No,
it's broken.
________
1. I still use Delphi 2 on Windows, and that debugger never worked right
either, so it's easy to forget...
John Seward
> application from the IDE.
Andreas,
Do you know if integrated debugging can be made to work in this
environment?
I've been wanting to work with Kylix for a long while, but haven't had
the opportunity. Now that I might get the chance, there's some growing
concern over its viability. For example, Borland's own page about the
product, at
http://shop.borland.com/dr/v2/ec_MAIN.Entry10?SP=10023&PN=1&V1=750285&xi
d=39696&CID=0&DSP=&CUR=840&PGRP=0&CACHE_ID=0 states:
"Please note that as a Classic Product, Borland offers no further
enhancements or support for this product."
I know that you've assembled a group of patches for Kylix, but I'm not
that aware of the details, and I haven't found an introduction, or
summary for applying the patches ("Here's what you need to do new user.
These are the important patches for everyone. Definitely apply these.
This other list of patches is only important if you need... or for
versions of Linux between 2.x.t and 2.y.z... ")
Additionally, it's rather scary to see "Hint: The Kylix IDE patches are
mostly outdated and are no longer developed." at the top of
http://andy.jgknet.de/oss/kylix/wiki/index.php/Kylix_IDE_patches
A major reason to get Kylix would be for its IDE and the integrated
debugging. Have I seen too many problem messages? Is installing Kylix
easier than it appears to someone who's only had newsgroup messages to
look at?
Like Forrest, I'd be very interested in getting (near?) full
functionality under Slackware 10.2 with Kernel 2.6.13.
Thank you very much for any advice! It will be VERY much appreciated,
as the thought of a learning curve for just INSTALLING Kylix, in
addition to the already existing steep learning curves for Linux, new
database environment, etc. etc. etc. may just stall the $2000 purchase.
Andreas Hausladen
> Do you know if integrated debugging can be made to work in this
> environment?
No It does not work with my SuSE 10.0 RC1 (Kernel 2.6.13-xx). And so I
asked "Forrest" if he had tested the integrated debugger, because on some
machines it meight work better than on other machines and distros like in
the past. But Kernel 2.6.11 broke the interated debugger and it is not
fixed till now. I heard from a patch for Kernel 2.6.13 but I had not the
time to test it. And this meight be till the end of next week.
> I know that you've assembled a group of patches for Kylix, but I'm not
> that aware of the details, and I haven't found an introduction, or
> summary for applying the patches ("Here's what you need to do new user.
I have two kinds of patches. The Unofficial VisualCLX patches and the
Kylix IDE patches which are no longer supported by me because most of them
are outdated or do no more work.
> Additionally, it's rather scary to see "Hint: The Kylix IDE patches are
> mostly outdated and are no longer developed." at the top of
> http://andy.jgknet.de/oss/kylix/wiki/index.php/Kylix_IDE_patches
I'm a single person with max. 2 distros installed on my PC. In the past it
was easy to have the Kylix IDE patches because the problem was not in the
kernel or there was a newer kernel which solved this problem (2.4.20 vs.
2.4.21). But now there is no newer kernel and I do not have the time to
keep all the patches working. For example the BC++ patches are a present
by me. I'm a Delphi guy not a C++ programmer (even if some people think
that I have C++ roots, that's not true). I never used Kylix (C++). The
only time I used it was to create the patch after I got many mails
requesting it.
> A major reason to get Kylix would be for its IDE and the integrated
> debugging.
And that's the reason why everybody wants a working debugger which is not
possible at the moment.
--
Regards,
Andreas Hausladen
(http://www.kylix-patch.de.vu - unofficial Kylix 3 patches)
(http://andy.jgknet.de/blog)
John Seward
Your one message with extended explanations helped me understand the
current state of Kylix with recent distros far more than lots of other
reading. Your generosity in terms of code and newsgroup contributions
has always amazed me (I've been watching these issues "from afar"), and
I can totally understand why a single person donating their time and
efforts would be overwhelmed with such a group of tasks.
In fact, I've been wondering if that isn't the way Borland feels, and
that there are other ways to handle (at least some of) these issues.
Linux is a rapidly moving target or rather: set of targets. It really
wouldn't pay to chase all of them; especially when the product
"competes" (in many people's minds, not ours) with so many free options.
In some ways, it seems to me that trying to constantly apply patches
for every change is like fighting malware (viruses, trojans, etc.) by
discovering them first, and then recognizing "signatures" and erasing
those files. It seems much easier, more efficient and safer to just
"close the doors" to these sorts of exploits in the first place,
instead of letting them in and then dealing with them.
Likewise, while I NEED to have the Kylix generated programs _running_
on later versions of the kernel (for good thread performance, closed
security exploits, etc.), it may be acceptable to install Kylix on a
2.4.x kernel development environment to have all the Kylix IDE features
working correctly. This does mean an extra layer of testing is
necessary to make sure the generated programs work as well on later OS
versions as the one you're developing on, but that seems likely to be
the case.
If this is true, wouldn't it be more productive of us Kylix users to
document which (later version) elements constitute GOOD development
environments within which to run Kylix, and recommend against using the
others? For example, the "good" kernels could be identified; perhaps
2.4.31 and 2.6.10?; then, the distros under which people know the IDE
works... etc...
Thanks again for your help.
Andreas Hausladen
> If this is true, wouldn't it be more productive of us Kylix users to
> document which (later version) elements constitute GOOD development
> environments within which to run Kylix, and recommend against using the
> others? For example, the "good" kernels could be identified; perhaps
> 2.4.31 and 2.6.10?; then, the distros under which people know the IDE
> works... etc...
The problem is that there are too many (unknown) variables. For me the
Kylix IDE worked on my SuSE 9.2 with the Xmodmap (ALT-GR patch) and an
export LD_ASSUME_KERNEL=2.4.1. But that is only on my old notebook and my
PC. Others with the same system but another CPU had no luck.
Dr. Edgar Alwers
> Likewise, while I NEED to have the Kylix generated programs _running_
> on later versions of the kernel (for good thread performance, closed
> security exploits, etc.), it may be acceptable to install Kylix on a
> 2.4.x kernel development environment to have all the Kylix IDE features
> working correctly.
Hopeless. It is like running after a train who started hours earlier and
hope that people in the stations will wait for those runners. In short
time, 2.4 kernels will be out. Think on KDE4 soon to be anounced , qt4
already state of the art and so on. Borland obviously decided, not to
support Kylix anymore on new kernel and Linux developments. Clearly, new
efforts dont pay for them. This has to be accepted. Not easy to understand
is that Borland refuses to submit the code to the open source community,
but anyway, this must also be accepted. So, there are two ways open: either
to try to port to Free Pascal ;-( or to c++ KDevelop + qt as I am doing,
also not the easy way. Life is hard !
Edgar
Den Jean
> So, there are two ways open: either
> to try to port to Free Pascal ;-( or to c++ KDevelop + qt as I am doing,
> also not the easy way. Life is hard !
We have ported all our Air Traffic Control apps
to fpc with a heavily patched clx. We did not use
any db stuff however. Currently some people are working
hard to get clx apps compiled without needing to patch clx.
be patient.
In parallell I am looking into creating a Qt4 binding for
pascal for clx. Lots of work, but feasible. My binding
generator allready was able to create a lib for
qapplication/qwidget/qpushbutton. A small test app that
only uses those flattened functions works.
It is similar to the work I have done for the Qt/Embbeded
binding I made, but just much more work. Qt4 is enormous.
I will first focus on only the functions used by CLX.
Qt/Embedded:
http://users.pandora.be/Jan.Van.hijfte/qtforfpc/qtedemo.html
ciao,
Den Jean
Dr. Edgar Alwers
> In parallell I am looking into creating a Qt4 binding for
> pascal for clx. Lots of work, but feasible.
This is really a very interesting work. However, a few questions: as the
binding of qt-4 means, that no old programs can just be ported to the new
software, do you think that there are any arguments in favor of the good
old pascal ? I mean, _what_are_the_arguments in favour of pascal instead of
c++ and, let me asume, kdevelop plus the same qt-4, which, in fact, seems
to be really very powerfull ?
We are used to pascal, that is true. But c++ is not so far away from pascal
anymore. I would guess, two months of intensive training with c++ will put
an experienced pascal programmer in the position to start programming in
c++ on a pretty nice level. I loved pascal, it was my favourite tool since
long time, I admired the stringency of the language. But I have to admit,
that c++ is today the state of the art e.g. in Linux programming. Is it so
much easier, to port to your new fpc+qt4 ( from Kylix !) than to code new
to c++ + qt4 ?
Very interested in your opinions !
Edgar
> Qt4 is enormous.
I agree ;-)
Den Jean
> Den Jean wrote:
>
>> In parallell I am looking into creating a Qt4 binding for
>> pascal for clx. Lots of work, but feasible.
>
> This is really a very interesting work.
And any help is always appreciated. I am looking for
serious people that create small pascal test programs that test
the allready ported functions.
> However, a few questions: as the
> binding of qt-4 means, that no old programs can just be ported to the new
> software, do you think that there are any arguments in favor of the good
> old pascal ? I mean, _what_are_the_arguments in favour of pascal instead
> of c++ and, let me asume, kdevelop plus the same qt-4, which, in fact,
> seems to be really very powerfull ?
> We are used to pascal, that is true. But c++ is not so far away from
> pascal anymore. I would guess, two months of intensive training with c++
> will put an experienced pascal programmer in the position to start
> programming in c++ on a pretty nice level. I loved pascal, it was my
> favourite tool since long time, I admired the stringency of the language.
> But I have to admit, that c++ is today the state of the art e.g. in Linux
> programming. Is it so much easier, to port to your new fpc+qt4 ( from
> Kylix !) than to code new to c++ + qt4 ?
Easier ? To create the Qt binding I had to fix many bugs in the moc parser,
something the average C++ programmer is not able too (just look at the
clueless moc trouble reports on the mailing lists). It is not that I do not
know C++, but everytime I use it, I get reminded as to why it is so much
better to progam in Pascal. BTW if you look at the Qt language (what you
write before the moc), you see an attempt to copy Delphi. Nevertheless I do
all this effort with the aim to be able to stick for development to a clean
language. I have to create and maintain Air Traffic Control programs. We
use ADA and Pascal. If you are under a high pressure to create stable
programs, it is so rewarding to use Pascal or ADA. BTW as soon as I start
using C-ish techniques in Pascal, it bites me back. Experience sounds
boring, but it just is true.
BTW I am not a single language fanatic, I used Python (well suited for the
task) to create this binding that itself is actually a C++/C library :-)
We also have a huge application base in CLX. It is not possible to port
this to C++ easily. I understand for new, small and short lived projects,
C++ is fine. But for huge programs you have to maintain a long time, Pascal
is much more rewarding. But KDE and so many other big programs ofcourse
prove the hard way is also possible :-)
regards,
Den Jean
Trane Francks
> old pascal ? I mean, _what_are_the_arguments in favour of pascal instead of
> c++ and, let me asume, kdevelop plus the same qt-4, which, in fact, seems
> to be really very powerfull ?
The first thing that comes to mind is that using native Pascal string
types protects one from the buffer overruns that are so commonly
exploited in C-based programs. When you overrun a buffer in C or C++,
you have a problem. When you stuff an overlength string into a Pascal
string variable, the excess is just discarded. Painless and safe.
It seems that Kylix 3 doesn't like something in Slackware 10.2. glibc,
perhaps? I don't know. Even with the 2.4.31 kernel, Kylix starts, but
does not exit cleanly (Delphi stays in memory and needs to be manually
killed). It really has become crucial for Borland to update this product
or open-source it.
trane
--
/////////////////////////////////////////////////////////
// Trane Francks tr...@gol.com Tokyo, Japan
// Practice random kindness and senseless acts of beauty.
Forrest
> It seems that Kylix 3 doesn't like something in Slackware 10.2. glibc,
> perhaps? I don't know. Even with the 2.4.31 kernel, Kylix starts, but
> does not exit cleanly (Delphi stays in memory and needs to be manually
> killed).
This one's particularly odd, since it wasn't happening under my
installation of the 10.1 version of slackware-current (which of course
virtually was 10.2).
Trane Francks
On 10/26/2005 07:56 PM +0900, Trane Francks wrote:
> Has anybody found a solution for this? I've experimented with various
> LD_ASSUME_KERNEL lines and whatnot, but the result is still the same:
> after upgrading from Slackware 10.1 to Slackware 10.2, the delphi
> executable stays in memory and needs to be killed manually.
Trane Francks
Has anybody found a solution for this? I've experimented with various
LD_ASSUME_KERNEL lines and whatnot, but the result is still the same:
after upgrading from Slackware 10.1 to Slackware 10.2, the delphi
executable stays in memory and needs to be killed manually.
Nemo Nihil
My solution was to keep Slack 10.1, and all is well. Am still
intending to deploy on later versions.
However: are you saying that the delphi executable exhibits that
behavior while developing/testing in the IDE, or when run independently
as well?
Trane Francks
> Trane,
Hi.
> My solution was to keep Slack 10.1, and all is well. Am still
> intending to deploy on later versions.
So far, any of my apps written in Kylix are fine in Slackware 10.2, so
deployment doesn't seem to be any more difficult in 10.2 than it was before.
> However: are you saying that the delphi executable exhibits that
> behavior while developing/testing in the IDE, or when run independently
> as well?
Basically, I haven't done much in Kylix since upgrading to Slack 10.2.
All is well, it seems, until Exit is called from the menu. At that
point, the Delphi executable goes into an apparent race condition and
load on the system increases. It's easy enough to live with. It's just a
minor annoyance that it needs to be manually killed. Unfortunately, it
is also further proof that Kylix having "Classic" status may not be
acceptable for very long. Whereas I can still use Turbo Pascal on Win 2K
and perhaps even XP VDMs as long as I have a < 2GB partition from which
to work, the Kylix IDE doesn't look as though it will age quite as well.
Shame, that. Oh, well.
Nemo Nihil
> Shame, that.
Yes, definitely. It's still my hope that with the increasing viability
of the Linux developer tools market, more people and companies using
Linux, and the new interest (and success?) from other development tools
companies selling their products, Borland will see fit to "resurrect"
this wonderful tool!
For now... it still is better than any other dev environment available!
Forrest
> I haven't done much in Kylix since upgrading to Slack 10.2.
> All is well, it seems, until Exit is called from the menu. At that
> point, the Delphi executable goes into an apparent race condition and
> load on the system increases. It's easy enough to live with. It's just a
> minor annoyance that it needs to be manually killed.
To my surprise and vague delight, this problem has vanished from my
-currentized 10.2 -- at least when using the supplied kernel 2.6.15.6.
I neglected to check under 2.4.32.