Re: [fpc-pascal] Defining sonames?

2017-08-18 Thread Martin Schreiber
On Friday 18 August 2017 12:45:26 Graeme Geldenhuys wrote:
> On 2017-08-18 10:27, Martin Schreiber wrote:
> > If one manually changes in link.res
>
> hahaha... You read my mind, I was going to try that today in my lunch
> time. :-)
>
> So now all that FPC needs is a new compiler parameter to tell it how to
> generate the linker parameters, and when the alternative is specified,
> not to strip the version info from the library name. That sounds doable
> with no immediate harm to existing projects (after all, it will be a new
> command line parameter).
>
Or simply treat a leading colon as start of a filename as ld does.

Martin
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Defining sonames?

2017-08-18 Thread Graeme Geldenhuys

On 2017-08-18 10:27, Martin Schreiber wrote:

the application links without errors despite there is no libX11.so ->
libX11.so.6 link.


I quickly tested under FreeBSD 10.3. Even thought FreeBSD doesn't have 
*-devel packages like Linux does. All ports packages (binary or build 
from source) include unversioned and versioned library names.


Anyway, the -l:libname.so.1 style linker parameter also works under 
FreeBSD. I could link a project without problems. To make doubly sure, I 
deleted the libX11.so symlink file and managed to link my project 
successfully. It also run without problems (didn't expect any issues 
here). So using the versioned library names definitely works.



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
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Defining sonames?

2017-08-18 Thread Graeme Geldenhuys

On 2017-08-18 10:27, Martin Schreiber wrote:

If one manually changes in link.res



hahaha... You read my mind, I was going to try that today in my lunch 
time. :-)


So now all that FPC needs is a new compiler parameter to tell it how to 
generate the linker parameters, and when the alternative is specified, 
not to strip the version info from the library name. That sounds doable 
with no immediate harm to existing projects (after all, it will be a new 
command line parameter).



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
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Defining sonames?

2017-08-18 Thread Martin Schreiber
On Friday 18 August 2017 10:56:47 Graeme Geldenhuys wrote:
> On 2017-08-18 08:16, Martin Schreiber wrote:
> > I checked with a simple library file, it seems that FPC strips the ".so*"
> > part from "external" names.
>
> Exactly what I discovered too. :-/
>
If one manually changes in link.res
"
INPUT(
-lX11
)
"
to
"
INPUT(
-l:libX11.so.6
)
"
the application links without errors despite there is no libX11.so -> 
libX11.so.6 link.

Martin
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Defining sonames?

2017-08-18 Thread Graeme Geldenhuys

On 2017-08-18 08:16, Martin Schreiber wrote:

I checked with a simple library file, it seems that FPC strips the ".so*" part
from "external" names.


Exactly what I discovered too. :-/


So the only way to make version-safe binding units in
Free Pascal seems to be to use dlopen()/dlsym().


That was my conclusion as well.

Regards,
  Graeme

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Defining sonames?

2017-08-18 Thread Graeme Geldenhuys

On 2017-08-18 06:28, Martin Schreiber wrote:

Did you remove the various {$linklib} statements too?
Did you check all units which where included by "uses" statements?


Yes to both.

Regards,
  Graeme

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Defining sonames?

2017-08-18 Thread Martin Schreiber
On Friday 18 August 2017 07:28:01 Martin Schreiber wrote:
> On Thursday 17 August 2017 22:20:44 Graeme Geldenhuys wrote:
> > On 2017-08-17 16:52, Martin Schreiber wrote:
> > > Exactly. So why not use the SONAME in the Pascal binding unit instead
> > > to use the base name as Free Pascal currently does in xlib.pp for
> > > example?
> >
> > I forked the xlib, xutils and x units from FPC and tried just that. It
> > made no difference.
>
> Did you remove the various {$linklib} statements too?
> Did you check all units which where included by "uses" statements?
> BTW I tried to fork xlib.pp too but gave up because of the too many files
> which hat do be forked and it was too dangerous for existing projects.
>
I checked with a simple library file, it seems that FPC strips the ".so*" part 
from "external" names. So the only way to make version-safe binding units in 
Free Pascal seems to be to use dlopen()/dlsym().
Is this intended?

Martin


___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Defining sonames?

2017-08-17 Thread Sven Barth via fpc-pascal
Am 18.08.2017 01:17 schrieb "Graeme Geldenhuys" <
mailingli...@geldenhuys.co.uk>:
>
> On 2017-08-17 21:47, Henry Vermaak wrote:
>>
>> You can use -l:libgreat.so.1 with gcc to link to a specific library
version
>> (iirc).
>
>
> I'll have to take your word for it Henry, as I don't know GCC much - only
the bare minimum to compile small C projects. I normally specify things
like -lpthreads -lX11 etc. I've never seen a versioned -l parameter being
used. I'll try it next time.

Passing a name with ":" to the linker works (on Linux at least). I used
that when I tested dynamic packages and wanted the linker to use
"librtl.ppl" instead of "librtl.so" ;)

Regards,
Sven
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Defining sonames?

2017-08-17 Thread Martin Schreiber
On Thursday 17 August 2017 22:20:44 Graeme Geldenhuys wrote:
> On 2017-08-17 16:52, Martin Schreiber wrote:
> > Exactly. So why not use the SONAME in the Pascal binding unit instead to
> > use the base name as Free Pascal currently does in xlib.pp for example?
>
> I forked the xlib, xutils and x units from FPC and tried just that. It
> made no difference.

Did you remove the various {$linklib} statements too?
Did you check all units which where included by "uses" statements?
BTW I tried to fork xlib.pp too but gave up because of the too many files 
which hat do be forked and it was too dangerous for existing projects.

Martin
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Defining sonames?

2017-08-17 Thread Graeme Geldenhuys

On 2017-08-17 22:17, Marco van de Voort wrote:

if some distribution halfway through the release cycle starts packaging a
new version.


But surely then the program would be broken anyway - in the case of a 
major version number bump. It is well known that major version changes 
mean two versions are NOT compatible.


What Martin is getting at is that by looking at the Object Pascal unit, 
one will then easily be able to see which major version of the library 
is supported by that header translation *.pp file. The linker will also 
complain and say that that specific library version is not install. 
That's a better error that some runtime crash or error about a API 
parameter that is now slightly different.


And just to be clear, by saying using the versioned library in the 
header translation unit, you will use the versioned library that only 
mentions the major version. eg:  'libgreat.so.1'and not 
'libgreat.so.1.2.7'


Either way, I tried the latter as I mentioned, and it made no difference 
to FPC. Somewhere the version info was stripped and only the base name 
was passed to the linker.


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
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Defining sonames?

2017-08-17 Thread Graeme Geldenhuys

On 2017-08-17 21:47, Henry Vermaak wrote:

You can use -l:libgreat.so.1 with gcc to link to a specific library version
(iirc).


I'll have to take your word for it Henry, as I don't know GCC much - 
only the bare minimum to compile small C projects. I normally specify 
things like -lpthreads -lX11 etc. I've never seen a versioned -l 
parameter being used. I'll try it next time.


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
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Defining sonames?

2017-08-17 Thread Sven Barth via fpc-pascal
Am 17.08.2017 22:20 schrieb "Graeme Geldenhuys" <
mailingli...@geldenhuys.co.uk>:
>
> On 2017-08-17 16:52, Martin Schreiber wrote:
>>
>> Exactly. So why not use the SONAME in the Pascal binding unit instead to
use
>> the base name as Free Pascal currently does in xlib.pp for example?
>
>
> I forked the xlib, xutils and x units from FPC and tried just that. It
made no difference. When I compiled the project with the -Cn command line
parameter I reviewed the ppas.sh and .res file. The .res file has
a INPUT section near the end listing all dependent libraries. They are
translated to the same as when you use GCC's -l command line parameter.
Only the base name of the library is used. Also, apparently the Unix/Linux
linker (FPC doesn't have it's own - only for Windows) doesn't support
versioned library names as command line parameters. So I don't think there
is much FPC can do - unless I'm still not understanding the whole compiling
and linking process, unless FPC implements their own linker under Unix-type
OSes too.

FPC does have its own, internal ELF linker, though that is not enabled by
default currently as it still has its shortcomings. But even then it would
follow the conventions of the target OS.

Regards,
Sven
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Defining sonames?

2017-08-17 Thread Marco van de Voort
In our previous episode, Martin Schreiber said:
> > nevertheless be failures if the applications
> > is programmed against the interface of the older v1 library (maybe they
> > changed the memory management for v2 and the problem will only manifest at
> > runtime).
> >
> Exactly. So why not use the SONAME in the Pascal binding unit instead to use 
> the base name as Free Pascal currently does in xlib.pp for example?

Because it is is not packaged with and meant only to work with only one .so
name. Changing it will only mean a lot of adminstration, and still breakage
if some distribution halfway through the release cycle starts packaging a
new version.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Defining sonames?

2017-08-17 Thread Henry Vermaak
On 17 Aug 2017 21:21, "Graeme Geldenhuys" 
wrote:

On 2017-08-17 16:52, Martin Schreiber wrote:

> Exactly. So why not use the SONAME in the Pascal binding unit instead to
> use
> the base name as Free Pascal currently does in xlib.pp for example?
>

I forked the xlib, xutils and x units from FPC and tried just that. It made
no difference. When I compiled the project with the -Cn command line
parameter I reviewed the ppas.sh and .res file. The .res file has
a INPUT section near the end listing all dependent libraries. They are
translated to the same as when you use GCC's -l command line parameter.
Only the base name of the library is used. Also, apparently the Unix/Linux
linker (FPC doesn't have it's own - only for Windows) doesn't support
versioned library names as command line parameters. So I don't think there
is much FPC can do - unless I'm still not understanding the whole compiling
and linking process, unless FPC implements their own linker under Unix-type
OSes too.


You can use -l:libgreat.so.1 with gcc to link to a specific library version
(iirc).

Henry
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Defining sonames?

2017-08-17 Thread Graeme Geldenhuys

On 2017-08-17 16:52, Martin Schreiber wrote:

Exactly. So why not use the SONAME in the Pascal binding unit instead to use
the base name as Free Pascal currently does in xlib.pp for example?


I forked the xlib, xutils and x units from FPC and tried just that. It 
made no difference. When I compiled the project with the -Cn command 
line parameter I reviewed the ppas.sh and .res file. The .res 
file has a INPUT section near the end listing all dependent libraries. 
They are translated to the same as when you use GCC's -l command line 
parameter. Only the base name of the library is used. Also, apparently 
the Unix/Linux linker (FPC doesn't have it's own - only for Windows) 
doesn't support versioned library names as command line parameters. So I 
don't think there is much FPC can do - unless I'm still not 
understanding the whole compiling and linking process, unless FPC 
implements their own linker under Unix-type OSes too.


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
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Defining sonames?

2017-08-17 Thread Martin Schreiber
On Thursday 17 August 2017 17:31:46 Sven Barth via fpc-pascal wrote:
> Am 17.08.2017 15:49 schrieb "Graeme Geldenhuys" <
>
> mailingli...@geldenhuys.co.uk>:
> > On 2017-08-16 18:14, Sven Barth via fpc-pascal wrote:
> >> As you can see the program will work correctly as long as the
> >> libX11.so.6 file exists (even though that is a symlink itself, but the
> >> X11 project guarantees that different libX11.so.6.x.y are compatible to
> >> eachother), because the linker picks the SONAME that is set inside the
> >> binary. And the libX11.so.6 symlink is part of the non-devel package.
> >
> > Sven, now here is an interesting problem regarding the way FPC (or Object
>
> Pascal in general) works with C based libraries. Martin pointed this out in
> another mailing list, and he gave me permission to forward it here. What is
> your answer or recommendation to this problem?
>
> Write in your application's readme which versions it requires. It might be
> true that the devel packages contain the C-headers, but there might
> nevertheless be failures if the applications
> is programmed against the interface of the older v1 library (maybe they
> changed the memory management for v2 and the problem will only manifest at
> runtime).
>
Exactly. So why not use the SONAME in the Pascal binding unit instead to use 
the base name as Free Pascal currently does in xlib.pp for example?

Martin
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Defining sonames?

2017-08-17 Thread Sven Barth via fpc-pascal
Am 17.08.2017 15:49 schrieb "Graeme Geldenhuys" <
mailingli...@geldenhuys.co.uk>:
>
> On 2017-08-16 18:14, Sven Barth via fpc-pascal wrote:
>>
>> As you can see the program will work correctly as long as the
>> libX11.so.6 file exists (even though that is a symlink itself, but the
>> X11 project guarantees that different libX11.so.6.x.y are compatible to
>> eachother), because the linker picks the SONAME that is set inside the
>> binary. And the libX11.so.6 symlink is part of the non-devel package.
>
>
> Sven, now here is an interesting problem regarding the way FPC (or Object
Pascal in general) works with C based libraries. Martin pointed this out in
another mailing list, and he gave me permission to forward it here. What is
your answer or recommendation to this problem?

Write in your application's readme which versions it requires. It might be
true that the devel packages contain the C-headers, but there might
nevertheless be failures if the applications
is programmed against the interface of the older v1 library (maybe they
changed the memory management for v2 and the problem will only manifest at
runtime).

Regards,
Sven
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Defining sonames?

2017-08-17 Thread Graeme Geldenhuys

On 2017-08-16 18:14, Sven Barth via fpc-pascal wrote:

As you can see the program will work correctly as long as the
libX11.so.6 file exists (even though that is a symlink itself, but the
X11 project guarantees that different libX11.so.6.x.y are compatible to
eachother), because the linker picks the SONAME that is set inside the
binary. And the libX11.so.6 symlink is part of the non-devel package.


Sven, now here is an interesting problem regarding the way FPC (or 
Object Pascal in general) works with C based libraries. Martin pointed 
this out in another mailing list, and he gave me permission to forward 
it here. What is your answer or recommendation to this problem?




 Forwarded Message 
Subject: Re: [MSEide-MSEgui-talk] MSE and XLib.
Date: Thu, 17 Aug 2017 14:54:16 +0200
From: Martin Schreiber
To: mseide-msegui-t...@lists.sourceforge.net

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



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
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Defining sonames?

2017-08-16 Thread Graeme Geldenhuys

On 2017-08-16 18:14, Sven Barth via fpc-pascal wrote:

Wrong. Take an empty program that includes the X unit:


In private I emailed Fred the following URL - it explains in plain 
English what is required and what really happens in the ELF binary 
format and such. Fred finally understood. On a side note: I learned 
something new too. :)


The information in your last reply was spot.

Here is the URL I send Fred. For anybody else, read the question and the 
first two answers - that should give you all the information anybody 
needs to understand the process.



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
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Defining sonames?

2017-08-16 Thread Sven Barth via fpc-pascal
On 14.08.2017 15:19, Fred van Stappen wrote:
> 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.

Wrong. Take an empty program that includes the X unit:

=== code begin ===

program tsoname;

uses
  X;

begin

end.

=== code end ===

The X unit simply contains a "$linklib x11" which is equivalent to
importing specific functions using "external 'x11' name ...".

My system looks like this:

=== listing begin ===

lrwxrwxrwx 1 root root  15 27. Feb 17:54 /usr/lib/libX11.so ->
libX11.so.6.3.0
lrwxrwxrwx 1 root root  15 27. Feb 17:54 /usr/lib/libX11.so.6 ->
libX11.so.6.3.0
-rwxr-xr-x 1 root root 1306096 27. Feb 17:54 /usr/lib/libX11.so.6.3.0

=== listing end ===

And the resulting binary links this (objdump -x output)

=== listing begin ===

(...)
Dynamic Section:
  NEEDED   libX11.so.6
  NEEDED   libc.so.6
(...)

=== listing end ===

As you can see the program will work correctly as long as the
libX11.so.6 file exists (even though that is a symlink itself, but the
X11 project guarantees that different libX11.so.6.x.y are compatible to
eachother), because the linker picks the SONAME that is set inside the
binary. And the libX11.so.6 symlink is part of the non-devel package.

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

Neither FPC nor the linker know anything about library versions. They
only know the filenames and the SONAMEs. If either can't find the
filename it needs than though luck. And the SONAME is the one that's
used for the real lookup, but the linker needs the file for that.

> Other thing.
> 
> If your way *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' ?

And did you even look at the code?

1. the libc unit is deprecated and only exists for Kylix compatibility
2. the LIBC_SO constant is used nowhere (the library constant is "clib"
and has the value 'c')

The only other use of "libc.so.6" is in iconvenc_dyn.pas, but that is
because it is loading the library dynamically and there the real file
*must* be used as the development symlink might not exist after all.

Regards,
Sven
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Defining sonames?

2017-08-15 Thread wkitty42

On 08/14/2017 09:19 AM, Fred van Stappen wrote:

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


ok, that's fine...


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.


yes... fpc could be using the libX11.so link... but it depends if a specific 
version is required... some do, some don't... it depends, too, on backward 
compatibility...



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



nope... because fpc doesn't care since it uses libX11.so which can point to 
whatever it needs to point to... the only way an error can happen with this is 
if the fpc program is performing some sort of version query on the .so that gets 
loaded... there's no problem with that, either, if that program requires a 
specific version of libX11... if there is a problem, then remove the update to 
7.0.1 and go back to 6.0.8 until the fpc program is updated for a higher version 
of libX11...



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.


libX11.so should be a symlink, too!

libX11.sp links to libX11.so.6
libX11.so.6   links to libX11.so.6.0
libX11.so.6.0 links to libXll.so.6.0.8 which is the real .so binary being 
used...

when the fpc program uses libX11.so, the links could be like this...

libX11.sp links to libX11.so.7
libX11.so.7   links to libX11.so.7.0
libX11.so.7.0 links to libXll.so.7.0.1 which should still work unless, as noted 
above, the fpc program requires an older version and does a version check or 
something...


ideally, the fpc program can check which .so names are available and choose the 
one closest to the beginning of the link chain that fits its needs... in other 
words, it can


1. check if libX11.so.6.0.8 exists if it requires v6.0.8. this is too strict!
2. check if libX11.so.6.0 exists if 6.0.8 does not exist.
3. check if libX11.so.6 exists if 6.0 does not exist.
4. check if libX11.so exists if 6 does not exist.

this is common and normal... if a specific version is still needed on the 
machine, it should still exist instead of being removed... that allows older 
programs requiring it to continue to work...



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 your way *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' ?


either one is fine... the latter being the last resort unless the former is 
required...




PS: Do not worry Marcov, it is my last post on fpc forum.



just my 2coins... i'm out, too ;)


--
 NOTE: No off-list assistance is given without prior approval.
   *Please keep mailing list traffic on the list unless*
   *a signed and pre-paid contract is in effect with us.*
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Defining sonames?

2017-08-15 Thread Fred van Stappen
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 your way *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' ?

PS: Do not worry Marcov, it is my last post on fpc forum.

Fre;D


___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Defining sonames?

2017-08-14 Thread Jonas Maebe

On 13/08/17 21:30, Fred van Stappen wrote:

You have a opinion that every respect, me first.



It's simply how it is and has been for the past 60 years or so.


Ha, ok, with this argument,


I was simply trying to clarify that Swen's description was not an 
opinion, but a fact of how things are. It's important in discussions to 
distinguish those two things.



I stop to try to change things.


As Marco said, you are complaining to the wrong people. We are not the 
ones that say that things should be done like this. It's the operating 
system packagers/maintainers that do so. Not following operating system 
conventions makes things harder in the long run, not easier. And it 
makes it harder to integrate seamlessly with other tool chains and work 
flows on such platforms. It also breaks expectations of long-time users 
of those platforms (since they know how things are supposed to work on 
their platform).



Jonas
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Defining sonames?

2017-08-14 Thread Fred van Stappen
> Exactly, and it is why, for each fpc version, the appropriate symlink should 
> be assigned ( at the moment libX11.so.6  )


And this is the OS, with his updates, that will assign symlink libX11.so.6 to 
the last installed libX11.6.1.2.3.4.so


Fre;D
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Defining sonames?

2017-08-13 Thread Fred van Stappen
>> You have a opinion that every respect, me first.

> It's simply how it is and has been for the past 60 years or so.

Ha, ok, with this argument, I stop to try to change things.

Sorry for the noise.

Fre;D
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Defining sonames?

2017-08-13 Thread Marco van de Voort
In our previous episode, Fred van Stappen said:
> But maybe it could be interesting to listen to other, even if you think
> that those people are stupid.

You are talking to the wrong people. If you think this behaviour is
incorrect, talk to the powers that be in charge of changing this (read:
Linux kernel and distribution maintenance)

Venting frustrations with *nix design on this list is futile.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Defining sonames?

2017-08-13 Thread Jonas Maebe

On 13/08/17 20:50, Fred van Stappen wrote:


You have a opinion that every respect, me first.


He gave a description of how linking against libraries from any language 
(C, Pascal, Go, Ada, ...) works on Unix-like systems. It is not related 
to opinions. It's simply how it is and has been for the past 60 years or so.


IMHO, like explained in package, the package contain symbolic link to 
the "developer" library.


A developer in this context is anyone to compiles/links programs that 
use this library (i.e., program developers). It's not about people who 
work on the library itself. They don't use the devel package, but the 
source.



Jonas
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Defining sonames?

2017-08-13 Thread Fred van Stappen
Please Sven, keep cool.


You have a opinion that every respect, me first.


But maybe it could be interesting to listen to other, even if you think that 
those people are stupid.


> The *-dev packages also contain the symbolic link from the library without 
> version to the versioned one.


IMHO, like explained in package, the package contain symbolic link to the 
"developer" library.

This library could not be the actual installed on the system (that is a link 
from libX11.so.6).


FPC acts like a "normal" user of libX11.so library, not as a developer (this is 
for C programmers who needs the C headers and work on the developer ibX11.so 
library.)


>  as the names of the library will change with every version.


Exactly, and it is why, for each fpc version, the appropriate symlink should be 
assigned ( at the moment libX11.so.6  )


> This *is* the way to do this


 This *is* your way to see this.


Fre;D


___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Defining sonames?

2017-08-13 Thread Sven Barth via fpc-pascal
Am 13.08.2017 17:42 schrieb "Fred van Stappen" :
>
> Hello Martin.
>
> Description of libx11-dev package (in /DEBIAN/control).
>
> Package: libx11-dev
> ...
> Description:
>
> This package contains the development headers for the library found in
libx11-6.
> Non-developers likely have little use for this package.
> ...
>
> Afaik, fpc does not use the C headers (I did not find it) nor fpc does
not develop/change anything inside the libX11 code.
> Maybe, but I have lot of doubt, fpc could need the C headers to compile
himself.
> But the compiled fpc should not need it.
>
> So, imho, in the case of fpc, they should not use libX11.so but
libX11.so.6 when linking things with the binary fpc.

The *-dev packages also contain the symbolic link from the library without
version to the versioned one. This *is* the way to do this as the names of
the library will change with every version.

Regards,
Sven
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Defining sonames?

2017-08-13 Thread Benito van der Zander

Hi,

 that reminds me of Synapse.


It is always very confusing to people that they need to install 
libssl-dev to use https, and libssl does not work.
Because libssl-dev contains libssl.so or so, while libssl only has 
libssl.so.1.0.0, which is not found...


And then you tell people to install libssl-dev, and they are even more 
confused, because they cannot find it, because they are on a 
distribution where they call it devel-openssl instead.



Cheers,
Benito



On 08/12/2017 04:54 PM, Fred van Stappen wrote:

Hello Martin.

Description of libx11-dev package (in /DEBIAN/control).

Package: libx11-dev
...
Description:
This package contains the development headers for the library found in 
libx11-6.

Non-developers likely have little use for this package.
...

Afaik, fpc does not use the C headers (I did not find it) nor fpc does 
not develop/change anything inside the libX11 code.
Maybe, but I have lot of doubt, fpc could need the C headers to 
compile himself.

But the compiled fpc should not need it.

So, imho, in the case of fpc, they should not use libX11.so but 
libX11.so.6 when linking things with the binary fpc.


My 0,001 cent.


Fre;D




___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal


___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Defining sonames?

2017-08-13 Thread Fred van Stappen
Hello Martin.

Description of libx11-dev package (in /DEBIAN/control).

Package: libx11-dev
...
Description:

This package contains the development headers for the library found in libx11-6.
Non-developers likely have little use for this package.
...

Afaik, fpc does not use the C headers (I did not find it) nor fpc does not 
develop/change anything inside the libX11 code.
Maybe, but I have lot of doubt, fpc could need the C headers to compile himself.
But the compiled fpc should not need it.

So, imho, in the case of fpc, they should not use libX11.so but libX11.so.6 
when linking things with the binary fpc.

My 0,001 cent.


Fre;D


___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Defining sonames?

2017-08-12 Thread Jonas Maebe

On 12/08/17 07:00, Martin Schreiber wrote:


MSEgui uses xlib by the units in packages/x11. The linker searches for
libX11.so which is not installed on most systems by default so one has to
install the libx11 devel package or manually create a symlink libX11.so ->
libX11.so.6 in order to compile MSEgui applications.


That is why it is called a devel package: you need it if you develop 
programs that use this library. That is how development works on Unix 
systems. We nor you can change that.



Some users are unable to cope with this or give up with the
comment "MSEide+MSEgui does not work on my system".


You can ask Linux distributions to make the MSEide+MSEgui package 
dependent on the x11 devel package. And maybe add some check in your own 
installation script as well, if you have one (or in the startup of the IDE).



Is it possible to add libX11.so.6 to the list of searched files for "X11"
externals without using dlopen/dlsym?


That would be wrong.


Jonas
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Defining sonames?

2017-08-12 Thread Michael Van Canneyt



On Sat, 12 Aug 2017, Martin Schreiber wrote:


Hi,

MSEgui uses xlib by the units in packages/x11. The linker searches for 
libX11.so which is not installed on most systems by default so one has to 
install the libx11 devel package or manually create a symlink libX11.so -> 
libX11.so.6 in order to compile MSEgui applications.
Some users are unable to cope with this or give up with the 
comment "MSEide+MSEgui does not work on my system".


Is it possible to add libX11.so.6 to the list of searched files for "X11" 
externals without using dlopen/dlsym?


The only way to do this is to change the lib name to libX11.so.6, as far as
I know. There may be some version script trickery, but that would probably
require additional compiler directives.

Michael.

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

[fpc-pascal] Defining sonames?

2017-08-11 Thread Martin Schreiber
Hi,

MSEgui uses xlib by the units in packages/x11. The linker searches for 
libX11.so which is not installed on most systems by default so one has to 
install the libx11 devel package or manually create a symlink libX11.so -> 
libX11.so.6 in order to compile MSEgui applications.
Some users are unable to cope with this or give up with the 
comment "MSEide+MSEgui does not work on my system".

Is it possible to add libX11.so.6 to the list of searched files for "X11" 
externals without using dlopen/dlsym?

Thanks, Martin
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal