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
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)
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
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
"
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
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 -
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
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 -
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
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
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
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
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
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
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
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
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
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
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
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,
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
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
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.
> 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
>> 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 -
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:
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
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.
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
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
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
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
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
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
34 matches
Mail list logo