[fpc-pascal] Re: linux: should we hard-code versioned or unversioned shared libraries in our apps?

Graeme Geldenhuys graemeg.lists at gmail.com
Thu Aug 16 09:50:51 CEST 2012


Hi,

On 16 August 2012 04:39, Marco van de Voort <marcov at stack.nl> wrote:
>
> Change in naming, (either root (gds->fbclient) or version numbers)

For God's sake!!! The gds -> fbclient was a once off deal after
Interbase was released to the open-source world and shortly thereafter
retracted that decision. The open source project continued (to
Borlands detriment), but to differentiate their work from the
commercial Interbase, they changed the library name. A once of deal -
as if this happens even second day! F*cken ridiculous argument.

As for version numbers... Major version numbers also take long to
change. How long has v2 been the major version number in Firebird,
FPC, etc?

> non
> standard directories (the $prefix/lib/mysql/ has been a problem in the
> past).

MYSQL is a mess, and my discussion about database libraries are
limited to Firebird only, as that is the only database we use in
commercial work. As for the location of 99.99% of libraries under
Linux.... that is defined by the OS and normally falls under /usr/lib
or /usr/lib64, and it has been like that since forever!


> And always, always, we work with 6 months to an year latency. If we were
> finalizing 2.6.2 now, and a distro had already changed in some devel
> version, it will probably not make 2.6.2.

Yes, and if you know anything amount maintaining commercial software,
you would know that NOBODY (in there right mind) would instantly jump
onto a new major version library change. It will probably require some
software update, lots of testing, new installs being generated, more
testing etc... another 6+ months latency. So again you "fear"
something that is not really an issue at all.


-- 
Regards,
  - Graeme -


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



More information about the fpc-pascal mailing list