Re: [MSEide-MSEgui-talk] MSE and XLib. @Graeme

[fredvs]

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! http://sdm.link/slashdot
___
mseide-msegui-talk mailing list
mseide-msegui-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk

Re: [MSEide-MSEgui-talk] MSE and XLib. @Graeme

[Martin Schreiber]

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 libX11-dev
>
It is named libx11-dev:
https://packages.ubuntu.com/artful/libx11-dev

> $ sudo apt-get install libXft-dev
> Reading package lists... Done
> Building dependency tree
> Reading state information... Done
> E: Unable to locate package libXft-dev
>
It is named libxft-dev:
https://packages.ubuntu.com/artful/libxft-dev

Martin

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
mseide-msegui-talk mailing list
mseide-msegui-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk

Re: [MSEide-MSEgui-talk] MSE and XLib. @Graeme

[fredvs]

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 lists... Done
Building dependency tree   
Reading state information... Done
E: Unable to locate package libXft-dev



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! http://sdm.link/slashdot
___
mseide-msegui-talk mailing list
mseide-msegui-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk

Re: [MSEide-MSEgui-talk] MSE and XLib. @Graeme

[fredvs]

> 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/

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
mseide-msegui-talk mailing list
mseide-msegui-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk

Re: [MSEide-MSEgui-talk] MSE and XLib.

[fredvs]

-- 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 agree with you too.

But for "conventional" applications only.

Take the example of this project:

https://github.com/fredvs/uidesigner_ext

It allows "Only One Instance" feature.

So, if a instance is already running, a new instance will only sent a
message to the first instance and then close itself.
And then that second instance will not charge/load all the X11/Xft/PThread
stuffs before to sent the message.

I did try with integration into ideU and indeed the message is sent much
faster.

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! http://sdm.link/slashdot
___
mseide-msegui-talk mailing list
mseide-msegui-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk

Re: [MSEide-MSEgui-talk] MSE and XLib.

[fredvs]

> > 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
  Delete(s,1,length(target_info.sharedclibprefix));
{ remove extension if any }
if
Copy(s,length(s)-length(target_info.sharedclibext)+1,length(target_info.sharedclibext))=target_info.sharedclibext
then
 
Delete(s,length(s)-length(target_info.sharedclibext)+1,length(target_info.sharedclibext)+1);
{ ready to be added }
SharedLibFiles.Concat(S);
  end;

But... it is hypra-simple to fix.  And it would not make any trouble for
previous code, it will be still compatible.

Sincerely I do absolutely not understand.

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! http://sdm.link/slashdot
___
mseide-msegui-talk mailing list
mseide-msegui-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk

Re: [MSEide-MSEgui-talk] MSE and XLib.

[fredvs]

> 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 dynamic linking".

"shared/dynamic" linking using libdl.so.2.:
I will call it "dl dynamic linking".

ot confuse "static" linking and "dynamic" 

> ld-linux.so.2 uses tables and library names built in in binary by "ld" at
> compile time
  Ha ok,   Huh, no way to create that tables at run time (and not use the
built in in binary) and use them at run time with  ld-linux.so.2 ?

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! http://sdm.link/slashdot
___
mseide-msegui-talk mailing list
mseide-msegui-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk

Re: [MSEide-MSEgui-talk] MSE and XLib.

[Martin Schreiber]

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.
> Could it be possible to use ld-linux.so.2 instead (with correspondent
> methods, of course) ?
>
I do not understand, ld-linux.so.2 uses tables and library names built in in 
binary by "ld" at compile time. libdl.so.2 (actually libc.so.6) uses library 
and function names provided as strings by the application at runtime. I 
assume internally dlopen()/dlsym() use functions from ld-linux.so.2.

> And for static linking that already uses ld-linux.so.2,
> if  if the "external" bug is fixed, a custom name/path of the library
> may be used and so have the advantage of a "dynlibs" way.
>
Static linking means combining *.o and *.a files by "ld" at compiletime and 
does not use libraries of the target system at runtime.
Please do not confuse "static" linking and "dynamic" or better named "shared" 
linking.
"shared/dynamic" linking comes in two flavors, either loading by ld-linux.so.2 
using link information stored in executable by "ld" at compiletime or by 
explicit calls of dlopen()/dlsym() in user code. Neither of them is 
named "static" linking.

Martin

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
mseide-msegui-talk mailing list
mseide-msegui-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk

Re: [MSEide-MSEgui-talk] MSE and XLib.

[fredvs]

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 correspondent 
methods, of course) ? 

And for static linking that already uses ld-linux.so.2, 
if  if the "external" bug is fixed, a custom name/path of the library 
may be used and so have the advantage of a "dynlibs" way.


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! http://sdm.link/slashdot
___
mseide-msegui-talk mailing list
mseide-msegui-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk

Re: [MSEide-MSEgui-talk] MSE and XLib.

[fredvs]

> 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 check.
Many thanks.

Each day it becomes clearer.

So, it I understand ok:

- There are 2 ways to load a library with Unix:

1)- With ld-linux.so.2
2)- With libdl.so.2

It seems (not sure, I want confirmation) that ld-linux.so.2 is better than
libdl.so.2 for speed, ressource used,...

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 correspondent
methods, of course) ?

All this if the "external" bug was not fixed.

Otherwise, if the "external" bug is fixed, a custom name/path of the library 
may be used (and so have the advantage of a "dynlibs" way).  


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! http://sdm.link/slashdot
___
mseide-msegui-talk mailing list
mseide-msegui-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk

Re: [MSEide-MSEgui-talk] MSE and XLib.

[Martin Schreiber]

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

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
mseide-msegui-talk mailing list
mseide-msegui-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk

Re: [MSEide-MSEgui-talk] MSE and XLib.

[Martin Schreiber]

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 linking code a {$linklib} statement (or Procedure
> dummy() ; cdecl; external libX11; ).
>
> Fre;D
>
Then the application can not start if the library is not found and it can not 
be compiled if there is no libX11.so -> libX11.so.6 link.

Martin

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
mseide-msegui-talk mailing list
mseide-msegui-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk

Re: [MSEide-MSEgui-talk] MSE and XLib.

[fredvs]

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 on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
mseide-msegui-talk mailing list
mseide-msegui-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk

Re: [MSEide-MSEgui-talk] MSE and XLib.

[fredvs]

> 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; external libX11; ).

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! http://sdm.link/slashdot
___
mseide-msegui-talk mailing list
mseide-msegui-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk

Re: [MSEide-MSEgui-talk] MSE and XLib.

[fredvs]

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 example in dynamic X11 header add this:

---> Procedure dummy() ; cdecl; external libX11;

Because of the use of "external", fpc will add -lX11 for the linker and then
the lib infos in ELF.

in link.res --->

INPUT(
-ldl
-lX11  -->  This was added by "external"
)

But, like you and I only know, "external" is buggy and will cut the ·so.n·
part of libX11. ;-(

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! http://sdm.link/slashdot
___
mseide-msegui-talk mailing list
mseide-msegui-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk

Re: [MSEide-MSEgui-talk] MSE and XLib.

[fredvs]

---> 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: 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! http://sdm.link/slashdot
___
mseide-msegui-talk mailing list
mseide-msegui-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk

Re: [MSEide-MSEgui-talk] MSE and XLib.

[fredvs]

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 must exist.

The soname is assigned with "external":

The soname is assigned with "external":

Example:
procedure XrmInitialize; cdecl; external libX11;

---

In xinerama.pp there the soname is "hardcoded", no constant or variable is
used:

They do:

function XineramaIsActive(dpy:PDisplay):TBoolResult;cdecl;external
'Xinerama';

And here also the linker automaticaly add "lib" + ".so"



In xft.pp there the nearly do the right way.

libXft = 'libXft.so';

Here the linker will not add prefix and suffix.

procedure XftDrawDestroy(draw : PXftDraw); cdecl; external libXft;

But the right way would be to use : libXft = 'libXft.so.2';
 

--


Huh, I have check all the fpc packages ---> all are wrong. ;-(

And I was also wrong saying that libc was ok.

In fact  LIBC_SO = 'libc.so.6'  ---> is never used.

In lbc.pp they do:

Const

 clib = 'c';  (the rigth way sould be : clib = ''libc.so.6')


Fre;D
 



--
View this message in context: 
http://mseide-msegui-talk.13964.n8.nabble.com/MSEide-MSEgui-talk-MSE-and-XLib-tp5p43.html
Sent from the mseide-msegui-talk mailing list archive at Nabble.com.

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
mseide-msegui-talk mailing list
mseide-msegui-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk

Re: [MSEide-MSEgui-talk] MSE and XLib.

[Sieghard]

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)
from the library the program uses directly & "physically" into the program
file itself. A statically linked program does not need any of the libraries
it's (statically) linked to.

> - Dynamicaly Linking = use libX11.so.6 = more freedom, can use dynlib

Dynamic linking means to insert
- a symbol table with library references &
- placeholders for any symbol references
"physically" into the program. The first measure then allows a "linking
loader" to gather all the relevant information to access all the library
symbols the program uses, and the second one allows the loader to insert
appropriate access code in place of the placeholders, "fixing up" the
program to allow it to access the library code directly after the library
has been loaded into memeory along with the program code.

Yet another method to use libraries dynamically, which doesn't seem to have
a commonly used name of its own, is to build code into the program that
can analyze a needed library, have it loaded into memory (either privately
for the program only or "publically" for access by other programs too), find
the pertinent symbols and set up any means needed to access them correctly.

While the former variant of dynamic linking can be fully performed by the
operating system, the latter has to be fully controlled by the program
using the linked library, although the system can provide means to support
the neccessary activities.

> That said, both linkings have advantages.
> 
> And I am not sure for libX11 that Staticaly Linking is the one I would
> choose.

Hardly, indeed. Any statically linked program contains _all_ of the library
code it uses, leading to multiple copies of this code in memory if several
such programs run in parallel, thus wasting memory. And libX11 will waste a
lot of memory.

> So, IMHO and, please, without opening any war, I would vote in a utopic
> world for a compiler that gives me the choice.

No war to "open", as this is by no means "utopic" - the Linux / Unix /
Windows linkers all give you the choice how to link your programs, you can
even mix static and both variants of dynamic linking in any single program.

> But, yes, I agree, it is twice the work to develop the package (and twice
> problems to debug it).

How? THere's _no_ more work needed for either method - they simply differ
by linker options.

> But do not worry, this will never append for fpc.

In fact, it already does. (Implying you wanted to write "apply" instead of
"append".)

-- 
-- 
(Weitergabe von Adressdaten, Telefonnummern u.ä. ohne Zustimmung
nicht gestattet, ebenso Zusendung von Werbung oder ähnlichem)
---
Mit freundlichen Grüßen, S. Schicktanz
---



--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
mseide-msegui-talk mailing list
mseide-msegui-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk

Re: [MSEide-MSEgui-talk] MSE and XLib.

[Sieghard]

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 linker doesn't support versioned library names, so how
> is FPC supposed to work around a Unix-type limitation?

Well, I _don't_ think this is a problem only fpc has. Any compiler has this
problem, even all C compilers. The reason why there's no uproar among C
users simply lies in the fact that any new version of a library, at least
in its development package, commonly provides all the needed C header files
also. As I see it, theses header files are the C equivalent to the "Pascal
C-library binding units" (or their source versions at least) that you're
discussing.
The "problem" arises simply because the system provided libraries are
developped in C, and thus the neccessary header files have to be created
anyway during development. _Any_ bindings for other languages - be it
Pascal, Perl, Python, Ada, FORTH, Smalltalk, Erlang, Java, even C++ - has
to be created specifically for this language. Even more, some languages
need "wrappers" for such libraries to allow them to access their code
(& possibly data).

> I fully agree the problem is not ideal, but the only possible solution
> for Pascal header translation units, is to have different units for
> different library versions. Think of the Qt header translations for

Right, just as the C header files for incompatible library versions have to
differ. Arent't there compatibility problems sometimes also? I think so.

> Object Pascal. It's a pain, but the pain we as Object Pascal developers
> have no live with when talking to libraries that are written in C/C++.

It _should_ be possible to write a C-header-to-Pascal translation utility,
which could even include a test for the correct library version at compile
time. If the "binding unit"'s version doesn't comply, a new one could
easily be created and its result used then.
(BTW, in the german Delphi news group, there's a member who announced he
was building a C-to-Pascal translator already, He gave the following link:
, C-to-Pascal Converter, by
Hans-Peter Diettrich. I've not come around to check it out yet, though...)

-- 
-- 
(Weitergabe von Adressdaten, Telefonnummern u.ä. ohne Zustimmung
nicht gestattet, ebenso Zusendung von Werbung oder ähnlichem)
---
Mit freundlichen Grüßen, S. Schicktanz
---



--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
mseide-msegui-talk mailing list
mseide-msegui-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk

Re: [MSEide-MSEgui-talk] MSE and XLib.

[Sieghard]

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 you need them in both cases, but the runtime loading requires more

So there's no difference in the amount of "work" needed for preparation.

> code to set everything up (granted that code only needs to be written
> once). Anyway, that's what I meant by "slightly less effort" when using
> static linking.

It seems to me that you referred to _using_ the library then, which was not
the topic above. _Creating_ the "header translation units" is a separate
step that's needed in preparation in any case. But this could possibly be
done automatically, please refer to my other reply.

-- 
-- 
(Weitergabe von Adressdaten, Telefonnummern u.ä. ohne Zustimmung
nicht gestattet, ebenso Zusendung von Werbung oder ähnlichem)
---
Mit freundlichen Grüßen, S. Schicktanz
---



--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
mseide-msegui-talk mailing list
mseide-msegui-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk

Re: [MSEide-MSEgui-talk] MSE and XLib.

[Martin Schreiber]

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 been discussed already many years ago without result so it will not 
be changed.

Martin

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
mseide-msegui-talk mailing list
mseide-msegui-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk

Re: [MSEide-MSEgui-talk] MSE and XLib.

[fredvs]

> 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 at Nabble.com.

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
mseide-msegui-talk mailing list
mseide-msegui-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk

Re: [MSEide-MSEgui-talk] MSE and XLib.

[fredvs]

> 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, voice-assisted ideU, etc).

I do usually like this: using program h2pas to translate the C header into
Pascal.

Then I have a custom template to convert all the code into "dynamic linking
header".

When this is done I begin to debug the header.

Huh, I have to confess you this:

I am a **huge** fan of dynamic linking, I find it fabulous, you get **much**
more freedom.

And if I did not for libX11 it it is because I trust Martin, he is muh more
competent than me, and if he see problems, there will have problems..

And it is not the amount of work,  I did it many times and know how to do.

Fre;D



--
View this message in context: 
http://mseide-msegui-talk.13964.n8.nabble.com/MSEide-MSEgui-talk-MSE-and-XLib-tp5p36.html
Sent from the mseide-msegui-talk mailing list archive at Nabble.com.

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
mseide-msegui-talk mailing list
mseide-msegui-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk

Re: [MSEide-MSEgui-talk] MSE and XLib.

[Martin Schreiber]

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

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
mseide-msegui-talk mailing list
mseide-msegui-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk

Re: [MSEide-MSEgui-talk] MSE and XLib.

[Graeme Geldenhuys]

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 how 
is FPC supposed to work around a Unix-type limitation?


I fully agree the problem is not ideal, but the only possible solution 
for Pascal header translation units, is to have different units for 
different library versions. Think of the Qt header translations for 
Object Pascal. It's a pain, but the pain we as Object Pascal developers 
have no live with when talking to libraries that are written in C/C++.


Would you mind if I forward your reply to the FPC mailing list to see 
what they think or recommend about such a situation?


Regards,
  Graeme

--
fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal
http://fpgui.sourceforge.net/

My public PGP key:  http://tinyurl.com/graeme-pgp

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
mseide-msegui-talk mailing list
mseide-msegui-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk

Re: [MSEide-MSEgui-talk] MSE and XLib.

[Martin Schreiber]

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 times...
>
> No, they are simply following the guidelines of Unix-type systems -
> doing everything correctly by the book.

A hypothetical example:

- You make a pascal bindings file for the "greatlibrary" version 1.0.
- You set the library name in the bindings pascal file "great.pas" to "great" 
as Unix-type systems guidelines command.
- In your system great-devel package of the version 1.0.1 is installed, you 
have the c-header *.h files of libgreat 1.0.1 and the links libgreat.so -> 
libgreat.so.1 -> libgreat.so.1.0.1.
- The SONAME of libgreat.so.1.0.1 is libgreat.so.1
- You compile and run the application, libgreat.so.1 -> libgreat.so.1.0.1 is 
loaded, all is OK.

Now you give the source of the application to a colleague who has installed 
the newer but incompatible "greatlibrary" version 2.0.3 including the devel 
package.
- He has the c-header *.h files of libgreat 2.0.3 and links libgreat.so -> 
libgreat.so.2 -> libgreat.so.2.0.3.
- The SONAME of libgreat.so.2.0.3 is libgreat.so.2
- He compiles your program, the linker links libgreat.so -> libgreat.so.2 -> 
libgreat.so.2.0.3 and stores the SONAME libgreat.so.2 (remember, 
libgreat.so.2 and libgreat.so.1 are *not* compatible).

Now there are two possibilities, maybe the function names in libgreat.pas did 
not change between version 1 and 2 -> the program compiles but crashes 
because of changed parameters or other incompatibilities.
Or it does not compile and then he needs to install version 1 
of "greatlibrary" and deinstall great-devel-2.0.3 and install 
great-devel-1.0.1 or change manually libgreat.so -> libgreat.so.2 to 
libgreat.so -> libgreat.so.1 temporarily.
This also must be done in first case in order to produce a working 
application.

The difference between a FPC bindings unit and a Unix C-header *.h file is 
that the *.h file is *included* in the devel-package and thus matches the 
installed version, the pascal file is not included but in a separate package 
or more likely taken from the FPC tar archive by the FPC install script 
because FPC Linux/FreeBSD-packages usually are too old or one wants to use a 
FPC version from SVN.
So the "guidelines for Unix-type systems" are not appropriate for Free Pascal 
C-library binding units IMHO.

Martin

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
mseide-msegui-talk mailing list
mseide-msegui-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk

Re: [MSEide-MSEgui-talk] MSE and XLib.

[Graeme Geldenhuys]

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 systems - 
doing everything correctly by the book. The recent URL I posted (see 
below) explains it in details. In short, the linker doesn't handle 
versioned names (it doesn't know how - even after 30 years). Hence when 
you compile C code with GCC, the -l parameter simply takes the base name 
of the library your code depends on. The 'lib' prefix and '.so' suffix 
are added later. The unversioned symlink supplies the correct versioned 
library information that must be added to the SONAME field in the ELF 
binary. The resulting binaries *always* point to versioned SO libraries, 
as ldd and objdump shows.



https://unix.stackexchange.com/questions/475/how-do-so-shared-object-numbers-work

Regards,
  Graeme

--
fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal
http://fpgui.sourceforge.net/

My public PGP key:  http://tinyurl.com/graeme-pgp

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
mseide-msegui-talk mailing list
mseide-msegui-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk

Re: [MSEide-MSEgui-talk] MSE and XLib.

[Martin Schreiber]

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 means that the library code is included in the 
executable normally by linking *.o or *.a files at compile time.
If one uses *.so's that means "shared linking" -> the library code is not 
contained in executable but loaded from target system at runtime.
There are two versions of shared linking, "statically shared" and "dynamically 
shared" (the terms vary).

With "statically shared" the linker at compiletime gets the "SONAME" of the 
given library, stores it in the executable and looks up the function 
references and sets table entries in the executable accordingly, which are 
resolved at runtime at startup by the linking loader of the target system.
That method is used by "xlib.pp". The executable can not start, if the needed 
*.so (defined by "SONAME") is not installed on the target system.
It can not be compiled, if the given library filename is not installed in the 
building system. 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...

Example:
xlib.pp has the libraryname "X11" -> the searched file at compiletime 
is "libX11.so". On my system this is a link
libX11.so -> libX11.so.6 -> libX11.so.6.3.0.
"
objdump -p libX11.so.6.3.0 | grep SONAME
"
Shows
"
  SONAME   libX11.so.6
"
-> the file searched at runtime startup is "libX11.so.6".
http://tldp.org/HOWTO/Program-Library-HOWTO/shared-libraries.html

"Dynamically shared" on the other hand is completely handled at runtime, in 
MSEgui applications normally by the functions in "msedynload.pas", especially 
initializedynlib(), which accepts a list of possible library filenames, a 
list of needed procedure-names/variables and a list of optional 
procedure-names/variables.
initializedynlib() internally uses dlopen() and dlsym() of the target system.
With this method the application can start even if the needed libraries are 
not installed in the target system.
http://tldp.org/HOWTO/Program-Library-HOWTO/dl-libraries.html

Martin

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
mseide-msegui-talk mailing list
mseide-msegui-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk

Re: [MSEide-MSEgui-talk] MSE and XLib.

[Graeme Geldenhuys]

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 
code to set everything up (granted that code only needs to be written 
once). Anyway, that's what I meant by "slightly less effort" when using 
static linking.


Regards,
  Graeme

--
fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal
http://fpgui.sourceforge.net/

My public PGP key:  http://tinyurl.com/graeme-pgp

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
mseide-msegui-talk mailing list
mseide-msegui-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk

Re: [MSEide-MSEgui-talk] MSE and XLib.

[Graeme Geldenhuys]

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 creating 
your own dynamic linking header units to any libraries you want or use.


Regards,
  Graeme

--
fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal
http://fpgui.sourceforge.net/

My public PGP key:  http://tinyurl.com/graeme-pgp

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
mseide-msegui-talk mailing list
mseide-msegui-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk

Re: [MSEide-MSEgui-talk] MSE and XLib.

[fredvs]

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 Linking is the one I would
choose.

So, IMHO and, please, without opening any war, I would vote in a utopic
world for a compiler that gives me the choice.

Or to link libX11 in my program Staticaly or Dynamicaly.

But, yes, I agree, it is twice the work to develop the package (and twice
problems to debug it).

But do not worry, this will never append for fpc.

Fre;D 





--
View this message in context: 
http://mseide-msegui-talk.13964.n8.nabble.com/MSEide-MSEgui-talk-MSE-and-XLib-tp5p28.html
Sent from the mseide-msegui-talk mailing list archive at Nabble.com.

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
mseide-msegui-talk mailing list
mseide-msegui-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk

Re: [MSEide-MSEgui-talk] MSE and XLib.

[Sieghard]

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 checked at compile time
>* dependency is checked immediately when you try and run the binary
>* 'ldd' can accurately report what is required (including versions) to
>  run the binary.

While these are valid arguments, isn't the main reason for pre-linking with
a dynamic library to enable the program loader to insert real adresses for
all references to library elements (to "patch them up"), so there's only
minimal overhead for any reference?
In contrast, a run-time-loaded dynamic library has to be parsed by the
program, references have to be set up as indirections (pointers) to the
elements used, either by setting up a call table or even creating
individual references for each use, and symbols have to be accessed
indirectly through these pointers.

>* 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, to know and to tell the compiler how to use any specific library
symbol? (I.e. commonly to call a function or procedure.)

-- 
-- 
(Weitergabe von Adressdaten, Telefonnummern u.ä. ohne Zustimmung
nicht gestattet, ebenso Zusendung von Werbung oder ähnlichem)
---
Mit freundlichen Grüßen, S. Schicktanz
---



--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
mseide-msegui-talk mailing list
mseide-msegui-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk

Re: [MSEide-MSEgui-talk] MSE and XLib.

[Martin Schreiber]

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" library
> and only load it (without to link it) ?
>
They could link to libX11.so.6 because there is probably no system which has 
libX11.so.5 today and if there is one it most likely is incompatible (thats 
the matter of major version numbers) and there probably never will be a 
libX11.so.7 because X11 "is dead anyway" and if there is one it will be 
incompatible.
I fear it will never happen, I long gave up on FPC for pragmatic solutions and 
changes on behalf of the users other than Delphi compatibility or the direct 
benefit for core members.

Martin

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
mseide-msegui-talk mailing list
mseide-msegui-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk

Re: [MSEide-MSEgui-talk] MSE and XLib.

[Graeme Geldenhuys]

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 accurately report what is required (including versions) to
run the binary.
  * I think creating header translation units are also slightly less
effort than runtime loading.

Regards,
  Graeme

--
fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal
http://fpgui.sourceforge.net/

My public PGP key:  http://tinyurl.com/graeme-pgp

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
mseide-msegui-talk mailing list
mseide-msegui-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk

Re: [MSEide-MSEgui-talk] MSE and XLib.

[fredvs]

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 this message in context: 
http://mseide-msegui-talk.13964.n8.nabble.com/MSEide-MSEgui-talk-MSE-and-XLib-tp5p24.html
Sent from the mseide-msegui-talk mailing list archive at Nabble.com.

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
mseide-msegui-talk mailing list
mseide-msegui-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk

Re: [MSEide-MSEgui-talk] MSE and XLib.

[fredvs]

> 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 all the x11, xutils, x etc header units to load
> at runtime
Yes, it is that my question.

> you can, but that would require much work - for little benefit I think.

OK,  I think that all is perfectly clear for me now.

Many thanks.

Fre;D






--
View this message in context: 
http://mseide-msegui-talk.13964.n8.nabble.com/MSEide-MSEgui-talk-MSE-and-XLib-tp5p23.html
Sent from the mseide-msegui-talk mailing list archive at Nabble.com.

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
mseide-msegui-talk mailing list
mseide-msegui-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk

Re: [MSEide-MSEgui-talk] MSE and XLib.

[Graeme Geldenhuys]

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 needed when you try and run 
your program (say on another system that do doesn't have development 
tools or libraries installed).




Could fpc do like it does for libc, consider libX11 as a "coomon" library
and only load it (without to link it) ?


Yes, but it really isn't needed. When linking occurs, the SONAME fields 
in a ELF binary get populated with the versioned shared library name. So 
the dependency is resolved to the exact version of the shared library 
that the binary needs for running.


If you did want to change all the x11, xutils, x etc header units to 
load at runtime, you can, but that would require much work - for little 
benefit I think. Plus, then the 'ldd' command will not display what the 
binary really needs to actually run.



Regards,
  Graeme

--
fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal
http://fpgui.sourceforge.net/

My public PGP key:  http://tinyurl.com/graeme-pgp

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
mseide-msegui-talk mailing list
mseide-msegui-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk

Re: [MSEide-MSEgui-talk] MSE and XLib.

[fredvs]

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 also few kb in the binary ?

Fre;D



--
View this message in context: 
http://mseide-msegui-talk.13964.n8.nabble.com/MSEide-MSEgui-talk-MSE-and-XLib-tp5p21.html
Sent from the mseide-msegui-talk mailing list archive at Nabble.com.

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
mseide-msegui-talk mailing list
mseide-msegui-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk

Re: [MSEide-MSEgui-talk] MSE and XLib.

[Graeme Geldenhuys]

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 follow. They all give vital information on how and why 
Unix-type systems work they way they do, and why unversioned symlink 
shared library files exist, and what they are needed for.


Regards,
  Graeme

--
fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal
http://fpgui.sourceforge.net/

My public PGP key:  http://tinyurl.com/graeme-pgp

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
mseide-msegui-talk mailing list
mseide-msegui-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk

Re: [MSEide-MSEgui-talk] MSE and XLib.

[fredvs]

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 context: 
http://mseide-msegui-talk.13964.n8.nabble.com/MSEide-MSEgui-talk-MSE-and-XLib-tp5p18.html
Sent from the mseide-msegui-talk mailing list archive at Nabble.com.

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
mseide-msegui-talk mailing list
mseide-msegui-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk

Re: [MSEide-MSEgui-talk] MSE and XLib.

[code dz]

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 me using fpc till now is
mseide/msegui and nothing else ;)

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
mseide-msegui-talk mailing list
mseide-msegui-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk

Re: [MSEide-MSEgui-talk] MSE and XLib.

[fredvs]

>  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 now.

I will stop to develop with fpc.

I was thinking to keep fpc for building libraries but the **huge** carence
in float calculation makes fpc not efficient.

Back to C.

Martin, of course, when mselang is ready, it will be a immense pleasure to
come back to my lovely Pascal language.

Many thanks for all.

Fre;D  







--
View this message in context: 
http://mseide-msegui-talk.13964.n8.nabble.com/MSEide-MSEgui-talk-MSE-and-XLib-tp5p16.html
Sent from the mseide-msegui-talk mailing list archive at Nabble.com.

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
mseide-msegui-talk mailing list
mseide-msegui-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk

Re: [MSEide-MSEgui-talk] MSE and XLib.

[Martin Schreiber]

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, mse could
> > have his own x11 code.
>
> I'll fork it and use initializedynlib() from msedynload which loads
> dynamically. It will take a while...

I reverted the changes. It is too dangerous and there must be forked too much 
because of the various {$linklib} statements in FPC code, sorry.

Martin

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
mseide-msegui-talk mailing list
mseide-msegui-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk

Re: [MSEide-MSEgui-talk] MSE and XLib.

[Fred van Stappen]

>> 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 something boring, the mail is loosed).

Fre;D
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
mseide-msegui-talk mailing list
mseide-msegui-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk

Re: [MSEide-MSEgui-talk] MSE and XLib.

[fredvs]

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.

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
mseide-msegui-talk mailing list
mseide-msegui-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk

Re: [MSEide-MSEgui-talk] MSE and XLib.

[Fred van Stappen]

> 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.

Total logic would be that fpc uses also libc-dev and his link libX11.so.

But in the fpc code they do:

LIBC_SO = 'libc.so.6' instead of LIBC_SO = 'libc.so'

So to follow their logic, it is a bug to not use 'libc.so' .

( But, for me it is the opposite, using LIBC_SO = 'libc.so' is a bug and using 
LIBC_SO = 'libc.so.6' is the right way ).

I am happy that you will do a MSE-libx11 (but I am sad that you did not 
understand what I try to explain).

Fre:D
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
mseide-msegui-talk mailing list
mseide-msegui-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk

Re: [MSEide-MSEgui-talk] MSE and XLib.

[Martin Schreiber]

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 initializedynlib() from msedynload which loads 
dynamically. It will take a while...
BTW, the code is not buggy. ;-)

Martin

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
mseide-msegui-talk mailing list
mseide-msegui-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk

Re: [MSEide-MSEgui-talk] MSE and XLib.

[Graeme Geldenhuys]

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 side) as you 
suggest.


Regards,
  Graeme

--
fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal
http://fpgui.sourceforge.net/

My public PGP key:  http://tinyurl.com/graeme-pgp

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
mseide-msegui-talk mailing list
mseide-msegui-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk

Re: [MSEide-MSEgui-talk] MSE and XLib.

[Fred van Stappen]

> 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 that fpc does need --> a wrong using of libxxx-dev.


Also, I did read the doc of linux- maintenance. The use of libxxx-dev is only 
for C developpers who wants to test the last dev-release.  And for this, they 
may use the c headers provided by  libxxx-dev + the "root-for-development" 
libxxx.so.


And all the blabla that the fpc gurus give is only blabla of lazy and old 
developers who do not want to change their mind.


But I see that nobody want to understand that I try to explain , so I give up. 
(Trust me, it is very rare, I usually never give up).


FreD


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
mseide-msegui-talk mailing list
mseide-msegui-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk

Re: [MSEide-MSEgui-talk] MSE and XLib.

[Fred van Stappen]

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 like they say, using lib**-dev is the rigth way then the 
code to lead libc is buggy.


Fre;D


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
mseide-msegui-talk mailing list
mseide-msegui-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk

Re: [MSEide-MSEgui-talk] MSE and XLib.

[Graeme Geldenhuys]

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 issue you mention is also 
not just limited to libX11.so, but to any libraries that FPC has header 
translations too. I have had similar issuer with database access too. 
It's annoying, but the way Unix-type systems have always worked. The 
*.so files (without version in the name) always links to the latest 
version. Luckily most libraries in Unix don't change major version 
numbers very often. ;-)  The other lucky thing is that backward 
compatibility with popular libraries are pretty darn good. No guarantee 
of that when major versions changes though, but still pretty good.


I guess what you are proposing is that the FPC in Free Pascal should be 
updated so also versioned libraries (probably with major version only. 
eg: libX11.so.6) are searched for. The issue has been around for so 
long, I doubt the FPC will bother making such a change. If somebody 
contributes such a patch, it might go some way to resolve the problem.



ps:
  I know the fcl-db code has been updated a few years back to
  search a few more named posibilities. But no other parts of
  the FCL was ever updated in a similar way.


Regards,
  Graeme

--
fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal
http://fpgui.sourceforge.net/

My public PGP key:  http://tinyurl.com/graeme-pgp

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
mseide-msegui-talk mailing list
mseide-msegui-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk

Re: [MSEide-MSEgui-talk] MSE and XLib.

[Fred van Stappen]

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, a system-update was done to the brand new version 
libX11.so.7.0.1,
this will update also libX11-dev >> libX11.so >> libX11.so.7.0.1.

And using fpc, there will be a error because libX11.so does not point to a 
libX11.so.6 version.

But if the same Linux/FreeBSD fpc release was compiled using symlink 
libX11.so.6, there, no problem, it will use the still installed symlink 
libX11.so.6.

Or, if libX11.so.6 is no more installed, fpc could say "libX11.so.6 not found" 
(because fpc knows now what version of libX11 he needs).

Other thing.

If it *is* the way to do, why fpc does not use libc6-dev (that will create 
symlink libc.so) but uses LIBC_SO = 'libc.so.6' instead of LIBC_SO = 'libc.so' ?

(By the way LIBC_SO = 'libc.so.6' **is** the correct way).

Fre;D




--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
mseide-msegui-talk mailing list
mseide-msegui-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk