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

2017-11-06 Thread 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!

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

2017-11-06 Thread 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

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

2017-11-06 Thread 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

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

2017-09-16 Thread fredvs
> ??? I made no patch? Nearly, you explained on this topic Sep 09, 2017; 9:59pm, how to fix it. Fre;D -- Sent from: http://mseide-msegui-talk.13964.n8.nabble.com/ -- Check out the vibrant tech community on one of

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

2017-09-16 Thread Martin Schreiber
On Saturday 16 September 2017 15:14:49 fredvs wrote: > > 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. ??? I made no patch? Martin

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

2017-09-16 Thread 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/

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

2017-09-16 Thread fredvs
Hello. If I may, in fpc there is /packages/libc/src/lib_namesh.inc for "compatibility with Xylix", with all the correct sonames. lib_namesh.inc Fre;D -- Sent from: http://mseide-msegui-talk.13964.n8.nabble.com/

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

2017-09-15 Thread Martin Schreiber
On Thursday 17 August 2017 15:25:29 Graeme Geldenhuys wrote: > 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

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

2017-09-09 Thread 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

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

2017-09-09 Thread 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

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

2017-09-09 Thread 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

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

2017-09-09 Thread 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. >

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

2017-09-09 Thread 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

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

2017-09-09 Thread 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

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

2017-09-09 Thread 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

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

2017-09-09 Thread 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

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

2017-09-09 Thread 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

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

2017-09-09 Thread 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;

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

2017-09-08 Thread 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

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

2017-09-06 Thread 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:

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

2017-08-18 Thread 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

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

2017-08-17 Thread 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)

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

2017-08-17 Thread 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

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

2017-08-17 Thread 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

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

2017-08-17 Thread 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

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

2017-08-17 Thread 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

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

2017-08-17 Thread 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,

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

2017-08-17 Thread 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

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

2017-08-17 Thread 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

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

2017-08-17 Thread 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

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

2017-08-17 Thread 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

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

2017-08-17 Thread 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

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

2017-08-16 Thread 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

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

2017-08-16 Thread 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

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

2017-08-16 Thread 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

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

2017-08-16 Thread 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

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

2017-08-16 Thread 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"

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

2017-08-16 Thread 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

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

2017-08-16 Thread 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

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

2017-08-16 Thread 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

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

2017-08-16 Thread 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

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

2017-08-16 Thread 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

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

2017-08-16 Thread 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

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

2017-08-16 Thread fredvs
Hello Martin. 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 To resume: libX11.so (and then libx11-dev) is needed for the linker only. Here part of answer of

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

2017-08-16 Thread 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

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

2017-08-15 Thread 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

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

2017-08-15 Thread 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

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

2017-08-15 Thread 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,

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

2017-08-14 Thread 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

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

2017-08-14 Thread 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.

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

2017-08-14 Thread 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.

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

2017-08-14 Thread 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

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

2017-08-14 Thread 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

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

2017-08-14 Thread 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

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

2017-08-14 Thread 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

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

2017-08-14 Thread 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

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

2017-08-14 Thread 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,