Ooops.
Well seen Martin.
Fre;D
--
Sent from: http://mseide-msegui-talk.13964.n8.nabble.com/
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org!
On Monday 06 November 2017 16:09:29 fredvs wrote:
> Sorry, I cannot resist.
>
> From Ubuntu 17.4 and child ( Mint, etc, ... ) -->
>
> $ sudo apt-get install libX11-dev
> Reading package lists... Done
> Building dependency tree
> Reading state information... Done
> E: Unable to locate package
Sorry, I cannot resist.
>From Ubuntu 17.4 and child ( Mint, etc, ... ) -->
$ sudo apt-get install libX11-dev
Reading package lists... Done
Building dependency tree
Reading state information... Done
E: Unable to locate package libX11-dev
$ sudo apt-get install libXft-dev
Reading package
> Probably the only argument Free Pascal people will accept. ;-)
Some wind says me that Code Typhon is busy to integrate Martin's patch into
next CT 6.4 release.
They are busy to test it on all their systems.
Fre;D
--
Sent from: http://mseide-msegui-talk.13964.n8.nabble.com/
-- This is continuation from a other MSE topic --
>>On 2017-09-08 19:18, Martin Schreiber wrote:
>> Free Pascal should allow to define the SONAME source in binding unit -
>> using
>> dlopen()/dlsym() instead is a hack IMHO.
>On 2017-09-08 20:18, Graeme wrote:
>I think so too.
OK, ok, I
> > Maybe in compiler/link.pas:509 (TLinker.AddSharedCLibrary()).
Procedure TLinker.AddSharedCLibrary(S:TCmdStr);
begin
if s='' then
exit;
{ remove prefix 'lib' }
if
Copy(s,1,length(target_info.sharedclibprefix))=target_info.sharedclibprefix
then
> I do not understand...
OK, I do understand now.
So it will not be possible to use ld-linux.so.2 for calling the library form
where/ when you want.
> Please do not confuse "static" linking and "dynamic"
OK. Let do like this:
"shared/dynamic" linking using ld-linux.so.2:
I will call it "ld
On Saturday 09 September 2017 14:49:43 fredvs wrote:
> Re-hello.
>
> Huh, in previous mail, at end please read this:
>
> The last war would be "What is better: libdl.so.2 or ld-linux.so.2 ?
>
> Could it be possible to imagine a different dynlibs.pas ?
> Actual dynlibs.pas is using libdl.so.2.
>
Re-hello.
Huh, in previous mail, at end please read this:
The last war would be "What is better: libdl.so.2 or ld-linux.so.2 ?
Could it be possible to imagine a different dynlibs.pas ?
Actual dynlibs.pas is using libdl.so.2.
Could it be possible to use ld-linux.so.2 instead (with
> Then the application can not start if the library is not found and
> it can not be compiled if there is no libX11.so -> ibX11.so.6 link.
Of course the "double advantage" works only if buggy "external" was fixed !
;-)
> Maybe in compiler/link.pas:509 (TLinker.AddSharedCLibrary()).
OK, I will
On Saturday 09 September 2017 13:35:18 fredvs wrote:
> Hello Martin.
>
> Do you know where in fpc code (or how to find it) "external" is assigned
> and 'so.n' deleted ?
>
Maybe in compiler/link.pas:509 (TLinker.AddSharedCLibrary()).
Martin
On Saturday 09 September 2017 12:53:22 fredvs wrote:
> > Another advantage of ld-linux.so.2 is that it is possible to list the
>
> needed libraries by "ldd ".
>
> Huh, it is what I try to explain: you may use dlopen()/dlsym() and list
> list the needed libraries by "ldd".
> ---> Add in dynamic
Hello Martin.
Do you know where in fpc code (or how to find it) "external" is assigned and
'so.n' deleted ?
Fre;D
--
Sent from: http://mseide-msegui-talk.13964.n8.nabble.com/
--
Check out the vibrant tech community
> Another advantage of ld-linux.so.2 is that it is possible to list the
needed libraries by "ldd ".
Huh, it is what I try to explain: you may use dlopen()/dlsym() and list list
the needed libraries by "ldd".
---> Add in dynamic linking code a {$linklib} statement (or Procedure
dummy() ; cdecl;
Hello Martin.
Did you know that you may combine static + dynamic linking?
I mean, take the advantage of static linking (adding some infos about the
library in ELF, more safe, ...)
and take the advantage of dynamic linking (using fast libdl.so library,
change name/dir of the lib, etc ...).
For
---> https://bugs.freepascal.org/view.php?id=32367
Answer: ... that will only lead to wars about what form should be default in
precompiled code.
---> "You wanted to avoid war at the price of dishonor. You have dishonor
and you will have war." W Churchill.
Fre;D
--
Sent from:
Hello.
Now that everybody "finally understood", let's do a resume.
The fpc code is perfect to show all the situations possible.
In xlib.pp they assigned as soname:
const
libX11='X11';
So, like perfectly explained in Graemes's infos, the linker automaticaly add
"lib" + ".so"
So a libX11.so
Sehr geehrter Herr fredvs,
Sie schrieben am Wed, 16 Aug 2017 17:50:29 -0500 (CDT):
> I am not sure about the terminology but let'say:
Yes.
> - Staticaly Linking = use libX11.so = store some data in ELF, more safe...
Static linking means to insert at least all of the code (& possibly data)
Sehr geehrter Herr Geldenhuys,
Sie schrieben am Thu, 17 Aug 2017 14:25:29 +0100:
> > So the "guidelines for Unix-type systems" are not appropriate for Free
> > Pascal C-library binding units IMHO.
>
> Indeed a valid problem, and something I have thought about myself. The
> problem being the
Sehr geehrter Herr Geldenhuys,
Sie schrieben am Thu, 17 Aug 2017 00:08:32 +0100:
> >> * I think creating header translation units are also slightly less
> >> effort than runtime loading.
> > Could you please explain? Don't you need the "header" information in any
> > case,
>
> Yes
On Thursday 17 August 2017 17:53:50 fredvs wrote:
> > A hypothetical example
>
> Huh, sorry, but what differs from the example that I post here and in fpc
> forum ?
>
Probably nothing. As I wrote before, FPC people probably misunderstood the
situation. Can happen, me and you too. ;-)
But it has
> A hypothetical example
Huh, sorry, but what differs from the example that I post here and in fpc
forum ?
Fre;D
--
View this message in context:
http://mseide-msegui-talk.13964.n8.nabble.com/MSEide-MSEgui-talk-MSE-and-XLib-tp5p37.html
Sent from the mseide-msegui-talk mailing list archive
> It's not the compiler that decides that
Yes, I know that, but it is fpc that gives the code of /packages/x11, it is
what I wanted to say.
> Nothing stops you from creating your own dynamic linking header.
Indeed. Creating dynamic Pascal linking header is my specialty. ( See
projects uos, sak,
On Thursday 17 August 2017 15:25:29 Graeme Geldenhuys wrote:
>
> Would you mind if I forward your reply to the FPC mailing list to see
> what they think or recommend about such a situation?
>
No problem, I have a "thick coat" as we speak in German. ;-)
Martin
On 2017-08-17 13:54, Martin Schreiber wrote:
So the "guidelines for Unix-type systems" are not appropriate for Free Pascal
C-library binding units IMHO.
Indeed a valid problem, and something I have thought about myself. The
problem being the linker doesn't support versioned library names, so
On Thursday 17 August 2017 10:54:31 Graeme Geldenhuys wrote:
> On 2017-08-17 07:18, Martin Schreiber wrote:
> > I don't understand why FPC uses the version-less library
> > names instead of the mayor version names where the bindings are made for.
> > Maybe a misunderstanding happened at ancient
On 2017-08-17 07:18, Martin Schreiber wrote:
I don't understand why FPC uses the version-less library
names instead of the mayor version names where the bindings are made for.
Maybe a misunderstanding happened at ancient times...
No, they are simply following the guidelines of Unix-type
On Thursday 17 August 2017 00:50:29 fredvs wrote:
> Hello.
>
> I am not sure about the terminology but let'say:
>
> - Staticaly Linking = use libX11.so = store some data in ELF, more safe...
>
> - Dynamicaly Linking = use libX11.so.6 = more freedom, can use dynlib
>
AFAIK statically linking
On 2017-08-16 22:08, Sieghard wrote:
* I think creating header translation units are also slightly less
effort than runtime loading.
Could you please explain? Don't you need the "header" information in any
case,
Yes you need them in both cases, but the runtime loading requires more
On 2017-08-16 23:50, fredvs wrote:
So, IMHO and, please, without opening any war, I would vote in a utopic
world for a compiler that gives me the choice.
It's not the compiler that decides that, its the developer and how he
implemented the header translation unit. Nothing stops you from
Hello.
I am not sure about the terminology but let'say:
- Staticaly Linking = use libX11.so = store some data in ELF, more safe...
- Dynamicaly Linking = use libX11.so.6 = more freedom, can use dynlib
That said, both linkings have advantages.
And I am not sure for libX11 that Staticaly
Sehr geehrter Herr Geldenhuys,
Sie schrieben am Wed, 16 Aug 2017 16:09:47 +0100:
> On 2017-08-16 15:46, fredvs wrote:
> > If you develop from scratch, what are the advantages to link a library
> > vs to load it dynamically ?
>
> From my personal point of view...
>
>* dependency is
On Wednesday 16 August 2017 15:52:38 fredvs wrote:
> Hello Graeme.
>
> OK, understood that libX11.so is needed for linking against that library.
>
> But ( aaargh, I am unbearable), is it really needed to link libX11.so ?
>
No.
> Could fpc do like it does for libc, consider libX11 as a "coomon"
On 2017-08-16 15:46, fredvs wrote:
If you develop from scratch, what are the advantages to link a library vs to
load it dynamically ?
From my personal point of view...
* dependency is checked at compile time
* dependency is checked immediately when you try and run the binary
* 'ldd' can
Re-re...-re hello.
I profit that I am still not banned from mse mailing-list.
(All development fora, when I ask things about linker --> or banned or
insulted (FreeBSD, fpc, ...).
If you develop from scratch, what are the advantages to link a library vs to
load it dynamically ?
Fre;D
--
View
> As I mentioned in a private message, the unversioned symlink shared library
files are only needed during linking time (ie: when you compile your
program).
Huh, I was asking if the fact of linking was absolutely necessary, not if
the unversioned symlink was needed.
> If you did want to change
On 2017-08-16 14:52, fredvs wrote:
But ( aaargh, I am unbearable), is it really needed to link libX11.so ?
As I mentioned in a private message, the unversioned symlink shared
library files are only needed during linking time (ie: when you compile
your program). Those symlink files are NOT
Hello Graeme.
OK, understood that libX11.so is needed for linking against that library.
But ( aaargh, I am unbearable), is it really needed to link libX11.so ?
Could fpc do like it does for libc, consider libX11 as a "coomon" library
and only load it (without to link it) ?
And that way, spare
On 2017-08-16 14:10, fredvs wrote:
Here better explanation of the utility of libX11.so (many thanks Graeme for
the infos).
https://unix.stackexchange.com/questions/475/how-do-so-shared-object-numbers-work
Yes, that is a very good explanation. Read the full question, and the
two answers that
Hello Wkitty.
Many thanks for your clear explanation in fpc-forum.
> the thing that keep me using fpc till now is mseide/msegui
Ha, I see that you have good taste so I will try imgui.
By the way, thanks for the many times you help me in Lazarus forum.
Fre;D
--
View this message in
i am also back to c/c++ about year ago now , i don't know why but
maybe because i feel comfortable with c/c++ more than pascal (less
restriction ;) ) also i am using imgui
(https://github.com/ocornut/imgui) its nice lightweight immediate
mode gui library .
but to be honest , the thing that keep
> reverted the changes. It is too dangerous and there must be forked too
much
> because of the various {$linklib} statements in FPC code
Ha, ok ;-(
I am very happy that fpc is twice the Project of the Month in Source Forge.
(I voted too).
There is also now a fpc donation, yep, they are rich
On Monday 14 August 2017 17:40:44 Martin Schreiber wrote:
> On Monday 14 August 2017 15:26:17 Fred van Stappen wrote:
> > Hello Martin.
> >
> >
> > May I ask you why MSE and fpGUI use the buggy code of fpc/packages/x11 ?
> >
> >
> > At the end it is only Pascal headers for the libX11.so library,
>> Why, for example for libc.so.6 (needed to compile fpc himself), fpc does not
>> use libc-dev and the libc.so created ?
> Good question, and I guess only the FPC compiler team can answer that.
Huh, I did ask it (now 14 hours ago) but still nothing in fpc-mailing list. (as
usual, when I ask
Ooops, in previous mail, please read:
libc-dev and his link libc.so.
Fre;D
--
View this message in context:
http://mseide-msegui-talk.13964.n8.nabble.com/MSEide-MSEgui-talk-MSE-and-XLib-tp5p13.html
Sent from the mseide-msegui-talk mailing list archive at Nabble.com.
> I'll fork it and use initializedynlib() from msedynload which loads
> dynamically. It will take a while...
Excellent idea and or freedom, I can be patient.
> BTW, the code is not buggy.
As explained to Graeme, if, like they said, the right way is to use lib***-dev
then there is a bug.
On Monday 14 August 2017 15:26:17 Fred van Stappen wrote:
> Hello Martin.
>
>
> May I ask you why MSE and fpGUI use the buggy code of fpc/packages/x11 ?
>
>
> At the end it is only Pascal headers for the libX11.so library, mse could
> have his own x11 code.
>
I'll fork it and use
On 2017-08-14 15:28, Fred van Stappen wrote:
Why, for example for libc.so.6 (needed to compile fpc himself), fpc does not
use libc-dev and the libc.so created ?
Good question, and I guess only the FPC compiler team can answer that.
But if true, it does sound a bit inconsistent (from their
> Why, for example for libc.so.6 (needed to compile fpc himself), fpc does not
> use libc-dev and the libc.so created ?
Sory, I am hot, I cannot resist.
For me, fpc act as very selfish. For himself and the libraries needed to
compile himself ---> ok, the good soname is used.
But for all
Hello Graeme.
Thank you to your answer but could you explain me why, if using lib**-dev
**is** the way to do, why fpc does it only for third library.
Why, for example for libc.so.6 (needed to compile fpc himself), fpc does not
use libc-dev and the libc.so created ?
I am very sorry but if
On 2017-08-14 14:34, Fred van Stappen wrote:
A Linux/FreeBSD fpc release was compiled using the pascal headers for libX11.so.6 and
using symlink libX11.so >> libX11.so.6.0.8.
Fred, as they tried to explain in the FPC mailing list, it is the way
Unix-type systems have worked for decades. The
Hello Martin
You know that I never give up.
A concrete example.
A Linux/FreeBSD fpc release was compiled using the pascal headers for
libX11.so.6 and using symlink libX11.so >> libX11.so.6.0.8.
This release was installed on a system (with libX11-dev too to make it work).
If, some time later,
52 matches
Mail list logo
