Re: [fpc-pascal] Re: fpdoc executable both in bin and utils\fpdoc - but not fpdoc.css
On Wed, August 15, 2012 04:07, waldo kitty wrote: > On 8/14/2012 09:47, michael.vancann...@wisa.be wrote: >> On Tue, 14 Aug 2012, Tomas Hajny wrote: >>> Actually, the file is more a configuration file for fpdoc than its >>> documentation, isn't it? From this point of view, shouldn't >>> SysUtils.GetAppConfigDir serve as the most reasonable location? >> >> It is definitely not a config file. It is a file that must be copied to >> every project you want to document with fpdoc. > > does that include FPC itself? > > it seems to me that folks questioning this install problem are talking > specifically about fpc documenting itself and where this file needs to be > for > the fpc documentation to work and look proper in an out of the box > installation > whether that is from some sort of installation program thing or whether it > is > via downloading the sources from SVN and building them with the make > system... > > the task of placing it correctly for one's own projects is another matter > completely... Please, re-read the thread. The "folks questioning this install problem" have explicitly been mentioning the use for documentation generation using the fpdoc tool, not issues with reading FPC docs in HTML format (which do include the file, but not all fpdoc users need to have FPC docs installed or use their HTML version plus they wouldn't know that they should refer to the docs directory for the CSS file when invoking fpdoc even if it is there for the HTML documentation reading). Tomas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: Get all caller adresses of a given function/procedure before executing
Am Wednesday 15 August 2012 03:52:00 schrieb waldo kitty:
> On 8/14/2012 03:11, Rainer Stratmann wrote:
> > Am Tuesday 14 August 2012 03:28:26 schrieb waldo kitty:
> >> i've been following this whole thread with interest... one thing that
> >> i'm still not clear about, though, is why is this important? is it to
> >> see what areas of the program are actually used or something else?
> >
> > Yes. It has to do with that.
>
> ok... that's one part that is understandable from a statistics POV...
I am not this experienced with the english language, so sorry if I do noz
understand everything 100%.
What means POV?
> >> in my mind, a multi-language tool will have all strings translated
> >> into the supported languages...
> >
> > The translation is a different thing to that.
>
> i don't understand... you have a list of the original strings and other
> lists of those strings translated into other languages... on startup, the
> program determines which language is chosen and it loads that translated
> language file... there is then no more translation needed... the program
> then simply uses those strings using the very same routines and no
> additional coding is needed... ???
Yes this way.
It can happen that a new text snippet is used in the program.
I use one file for all translations.
> >> if there are some that are ambiguous or used in a different
> >> way, then they would get broken down further for proper language
> >> constructs...
> >
> > I do not understand this...
>
> consider in english we might say "she opened the door" but in another
> language they might use the format of "door opened she"... basically what
> i'm trying to say is that the constructs of the sentences may be
> different...
Yes, then the whole sentence has to be translated.
> my comment above was looking that one might have to break down
> that sentence "she opened the door" into multiple parts so that the
> translation would be performed and assembled in the output of the program
> easier...
In my program there are 2 types:
1. Easy to translate words or little sentences.
2. User manual with longer Text.
>
> >> while i have numerous tools and utils out in the wild being
> >> used on a daily bases, none of them are multi-language but i do look
> >> forward to the day when i can produce such with minimal effort in
> >> coding... i have to leave it to others to do the actual translations,
> >> though...
> >
> > I put only ls('snippet1'), ls('snippet2'), ls('snippet3')... around the
> > text everywhere I want a translation.
>
> this would be no different than the program doing
>writeln(snippet1);
But then you have to define snippet1 (pascal language identifyer in your
example). I do not need to define snippet1 somewhere else.
writeln( ls( 'snippet1' ) );
snippet1 here is the text (in my case in germany) already.
It is the written text and also the identifyer.
> when all strings are translated and stored in some translated language
> file... snippet1 in english would be the same snippet1 in german, dutch,
> japanese, etc... it is my understanding that this is also the way the
> existing *.po files work... the code simply loads english.po or german.po
> or klingon.po at the start of the program and after that, everything is the
> same...
I do not know how the different *.po files work.
>
> > This is also better if you are searching for text in the program. You
> > find then exactly the position you want.
>
> i understand what you are saying but i don't understand why... since you
> mentioned an online translation service, are you looking at using live
> translations instead of static ones stored in a language file??
The users (in their countries) can translate may be better then I can so.
For the english language I can do. Most people can understand english and from
that language translate in their own language.
>
> [trim]
>
> > You can make other tables (or fields in an array) for each translation
> > for example. The translation is done somewhere else (for example online
> > http://109.91.95.104/sprache).
>
> so you are looking to perform live translations, then? what if that
> translation service disappears tomorrow? what about your users then?
What do you mean with live translations exactly?
The web server and translation service I program myself.
So it is available I think longer than until tomorrow.
> > There is a file with all snippets and translations (handles _not_
> > included, because they may change with each execution of the program).
>
> i don't see how a language can change from one day to the next or even one
> execution to the next...
One user uses english translation and the other dutch translation.
It is far more easier for me to put all languages in one file, because of less
administration overhead then.
If the languages are in one file I can also easily add a creation date, add
date for changed entries (date of creation, date of change) and so on...
Whatever I want and need for better administrati
Re: [fpc-pascal] Re: Get all caller adresses of a given function/procedure before executing
Am Wednesday 15 August 2012 04:05:56 schrieb Martin:
> On 15/08/2012 02:52, waldo kitty wrote:
> > this would be no different than the program doing
> >
> > writeln(snippet1);
>
>
>
> > .i must still be missing something :?
>
> If I understood him correct:
>
> It is not
> writeln(snippet1);
> it is
> writeln('snippet1');
It is writeln( ls( 'snippet1' ) );
> With quotes.
> He does want (or already has) the text snippets as in-lined constants.
in-lined constants ???
> He does not want to do the work of maintain them in another place (which
> an array, or resource string would require.)
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: Get all caller adresses of a given function/procedure before executing
Am Wednesday 15 August 2012 09:33:37 schrieb Rainer Stratmann: > What means POV? Ok. Point of view I assume. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Re: Get all caller adresses of a given function/procedure before executing
On 15/08/2012 08:33, Rainer Stratmann wrote:
> Am Wednesday 15 August 2012 03:52:00 schrieb waldo kitty:
>> the loading code simply
>> chooses the proper po file and then loads the strings into an array or
>> whatever using the same variables which are used everywhere no matter what
>> language their contents are written in...
>
> Do you need a separate pascal identifier for each snippet?
>
>> i must still be missing something :?
No with (dx)gettext you don't need pascal identifiers for every string.
And the translating function is _():string;
So all you do is writeln(_('snippet1'));, to follow your convention.
So it more or less uses the same idea as you are trying to replicate.
L.
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: Get all caller adresses of a given function/procedure before executing
Am Wednesday 15 August 2012 09:59:00 schrieb Lukasz Sokol:
> On 15/08/2012 08:33, Rainer Stratmann wrote:
> > Am Wednesday 15 August 2012 03:52:00 schrieb waldo kitty:
> >> the loading code simply
> >> chooses the proper po file and then loads the strings into an array or
> >> whatever using the same variables which are used everywhere no matter
> >> what language their contents are written in...
> >
> > Do you need a separate pascal identifier for each snippet?
> >
> >> i must still be missing something :?
>
> No with (dx)gettext you don't need pascal identifiers for every string.
> And the translating function is _():string;
> So all you do is writeln(_('snippet1'));, to follow your convention.
>
> So it more or less uses the same idea as you are trying to replicate.
>
Yes, that is possible as I understand it so far.
I did not know (dx)gettext before so replication is may not the right word.
My solution will be more flexible I assume.
I put already some hours in it and I like to write my own code so I follow the
already driven way.
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Re: Get all caller adresses of a given function/procedure before executing
On 15-8-2012 10:08, Rainer Stratmann wrote:
> Am Wednesday 15 August 2012 09:59:00 schrieb Lukasz Sokol:
>> On 15/08/2012 08:33, Rainer Stratmann wrote:
>>> Am Wednesday 15 August 2012 03:52:00 schrieb waldo kitty:
the loading code simply
chooses the proper po file and then loads the strings into an array or
whatever using the same variables which are used everywhere no matter
what language their contents are written in...
>>>
>>> Do you need a separate pascal identifier for each snippet?
>>>
i must still be missing something :?
>>
>> No with (dx)gettext you don't need pascal identifiers for every string.
>> And the translating function is _():string;
>> So all you do is writeln(_('snippet1'));, to follow your convention.
>>
>> So it more or less uses the same idea as you are trying to replicate.
>>
> Yes, that is possible as I understand it so far.
> I did not know (dx)gettext before so replication is may not the right word.
Yes, it is. Replication is doing the same thing twice, regardless of the
reasons/knowledge behind that fact.
> My solution will be more flexible I assume.
> I put already some hours in it and I like to write my own code so I follow
> the
> already driven way.
I haven't used dxgettext, but would ask you to have a serious look at
it. Presumably dxgettext users/developers had many of the same problems
you face and have created solutions for those problems over the years.
I understand you take pride in your own code and it feels like wasted
effort to dump it, but using a set of proven code may be advantageous.
You can still submit your own improvements to dxgettext if you hit
problems... and if those aren't accepted, in the worst case create your
own fork.
You already have a very good grasp of the issues involved as you were
writing your own solution. You could probably improve dxgettext with
some things and get that in the main development tree, thereby improving
things for others.
The other way round also works: other peoples' improvements can end up
in your code for free (almost: you'll need some
implementation/verification time).
While this may all be very well known to you, I would ask you to step
back and consider it: having a detached look at it may lead to a better
choice.
Just my 2 cents,
regards,
Reinier
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: Get all caller adresses of a given function/procedure before executing
Am Wednesday 15 August 2012 10:20:34 schrieb Reinier Olislagers: > On 15-8-2012 10:08, Rainer Stratmann wrote: > > Yes, that is possible as I understand it so far. > > I did not know (dx)gettext before so replication is may not the right > > word. > > Yes, it is. Replication is doing the same thing twice, regardless of the > reasons/knowledge behind that fact. I you want call it replication. > > My solution will be more flexible I assume. > > I put already some hours in it and I like to write my own code so I > > follow the already driven way. > > I haven't used dxgettext, but would ask you to have a serious look at > it. Presumably dxgettext users/developers had many of the same problems > you face and have created solutions for those problems over the years. > I understand you take pride in your own code and it feels like wasted > effort to dump it, but using a set of proven code may be advantageous. > > You can still submit your own improvements to dxgettext if you hit > problems... and if those aren't accepted, in the worst case create your > own fork. My style of coding is normally in general writing an own solution. So I did it with a webserver also. Advantages are the flexibility. And a disadvantage is may the longer time to find a solution. But this fact relativizes the more specific the solution will be. I made the experience that the spent time will be the same (or even less if you exactly know what is needed) then. If you are searching for an individual solution that is not done before than you have to ask the developers and hope that they support you. If not you have to find yourself a solution. > You already have a very good grasp of the issues involved as you were > writing your own solution. You could probably improve dxgettext with > some things and get that in the main development tree, thereby improving > things for others. As I read now here http://dxgettext.po.dk/ gettext seems already to be a (very) good solution. I am wondering why there are some problems with as I read somewhere in this thread. > The other way round also works: other peoples' improvements can end up > in your code for free (almost: you'll need some > implementation/verification time). > > While this may all be very well known to you, I would ask you to step > back and consider it: having a detached look at it may lead to a better > choice. For me it would be interesting to know how dxgettext gets the snippet information from the program code...! > Just my 2 cents, > > regards, > Reinier > ___ > fpc-pascal maillist - fpc-pascal@lists.freepascal.org > http://lists.freepascal.org/mailman/listinfo/fpc-pascal ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Re: fpdoc executable both in bin and utils\fpdoc - but not fpdoc.css
On 14-8-2012 20:50, Michael Van Canneyt wrote: > On Tue, 14 Aug 2012, Reinier Olislagers wrote: >> On 14-8-2012 16:03, >> michael.vancanneyt-0is9kj9sb0a-xmd5yjdbdmrexy1tmh2...@public.gmane.org >> wrote: >>> Thinking about it, I will change fpdoc so it does not need the file >>> installed, but generates it if not present, as Graeme suggested. >>> >>> That will be far easier, and causes less headaches and discussion. > > Implemented it. Revision 22079. > > The --css-file option is still honored. If it is not specified, a > built-in copy is written to the appropriate place. Thanks a lot Michael! I am perhaps doing something wrong when testing it? FPC x86 windows r22081 Getting a baseline: this one C:\Development\fpctrunk\bin\i386-win32>fpdoc --package=fcl --input=C:\Development\fpctrunk\packages\paszlib\src\zipper.pp --descr=D:\Reinier\Documents\SourceCode\fpc_laz_patch_playground\docs\paszlib.xml --format=chm --css-file=C:\Development\fpctrunk\utils\fpdoc\fpdoc.css --output=d:\cop\CSSSpecified.chm gives a chm with a blue bar with index and #fcl on top chmls list d:\cop\CSSSpecified.chm | grep -i css shows there is an fpdoc.css in the chm, as expected. IIUC, at least one of these should use the embedded fpdoc.css, but neither does (no blue bar on top, no fpdoc.css found in the chm): C:\Development\fpctrunk\bin\i386-win32>fpdoc --package=fcl --input=C:\Development\fpctrunk\packages\paszlib\src\zipper.pp --descr=D:\Reinier\Documents\SourceCode\fpc_laz_patch_playground\docs\paszlib.xml --format=chm --css-file= --output=d:\cop\CSSEmpty.chm chmls list d:\cop\CSSEmpty.chm | grep -i css indeed shows no fpdoc.css in the chm C:\Development\fpctrunk\bin\i386-win32>fpdoc --package=fcl --input=C:\Development\fpctrunk\packages\paszlib\src\zipper.pp --descr=D:\Reinier\Documents\SourceCode\fpc_laz_patch_playground\docs\paszlib.xml --format=chm --output=d:\cop\CSSNotSpecified.chm chmls list d:\cop\CSSNotSpecified.chm | grep -i css indeed shows no fpdoc.css in the chm ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: Get all caller adresses of a given function/procedure before executing
On Wed, Aug 15, 2012 at 10:20:34AM +0200, Reinier Olislagers wrote:
> On 15-8-2012 10:08, Rainer Stratmann wrote:
> > Am Wednesday 15 August 2012 09:59:00 schrieb Lukasz Sokol:
> >> On 15/08/2012 08:33, Rainer Stratmann wrote:
> >>> Am Wednesday 15 August 2012 03:52:00 schrieb waldo kitty:
> the loading code simply
> chooses the proper po file and then loads the strings into an array or
> whatever using the same variables which are used everywhere no matter
> what language their contents are written in...
> >>>
> >>> Do you need a separate pascal identifier for each snippet?
> >>>
> i must still be missing something :?
> >>
> >> No with (dx)gettext you don't need pascal identifiers for every string.
> >> And the translating function is _():string;
> >> So all you do is writeln(_('snippet1'));, to follow your convention.
> >>
> >> So it more or less uses the same idea as you are trying to replicate.
> >>
> > Yes, that is possible as I understand it so far.
> > I did not know (dx)gettext before so replication is may not the right word.
> Yes, it is. Replication is doing the same thing twice, regardless of the
> reasons/knowledge behind that fact.
I'm not sure about that since replication isn't really a word, although it
has crept into the English language. I look at it from a results POV rather
from an action POV. Replication is about producing copies of the same
result. You can do a similar action multiple times (duplication) and produce
a dissimilar result. That wouldn't be replicating anything, it would just be
a duplication of effort.
>From a database POV (which is how I know what little I know about
replication since I was involved in a project to do this in the early 1990s
before the whole db replication thing got so commonplace) the word
replication means not that anything was done more than once, but that the
one result was propagated to multiple places. So it seems to me replication
is about multiple result instances, not multiple action instances.
--
_ _
._ _ _ <_> ___ _ _ ___ ___ ___ _| | ___
| ' ' || |/ | '| '_>/ . \/ | '/ . \/ . |/ ._>
|_|_|_||_|\_|_.|_| \___/\_|_.\___/\___|\___.
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: Get all caller adresses of a given function/procedure before executing
"And a
disadvantage is may the longer time to find a solution."
Thats not the only disadvantage. Reinventing the wheel usually means
you get something less correct and less researched. Its simple, 1000
eyes looking for a bug into a standard library will spot much more
problems than your lone eye looking for a bug into your own
implementation.
2012/8/15 :
> On Wed, Aug 15, 2012 at 10:20:34AM +0200, Reinier Olislagers wrote:
>> On 15-8-2012 10:08, Rainer Stratmann wrote:
>> > Am Wednesday 15 August 2012 09:59:00 schrieb Lukasz Sokol:
>> >> On 15/08/2012 08:33, Rainer Stratmann wrote:
>> >>> Am Wednesday 15 August 2012 03:52:00 schrieb waldo kitty:
>> the loading code simply
>> chooses the proper po file and then loads the strings into an array or
>> whatever using the same variables which are used everywhere no matter
>> what language their contents are written in...
>> >>>
>> >>> Do you need a separate pascal identifier for each snippet?
>> >>>
>> i must still be missing something :?
>> >>
>> >> No with (dx)gettext you don't need pascal identifiers for every string.
>> >> And the translating function is _():string;
>> >> So all you do is writeln(_('snippet1'));, to follow your convention.
>> >>
>> >> So it more or less uses the same idea as you are trying to replicate.
>> >>
>> > Yes, that is possible as I understand it so far.
>> > I did not know (dx)gettext before so replication is may not the right word.
>> Yes, it is. Replication is doing the same thing twice, regardless of the
>> reasons/knowledge behind that fact.
>
> I'm not sure about that since replication isn't really a word, although it
> has crept into the English language. I look at it from a results POV rather
> from an action POV. Replication is about producing copies of the same
> result. You can do a similar action multiple times (duplication) and produce
> a dissimilar result. That wouldn't be replicating anything, it would just be
> a duplication of effort.
>
> >From a database POV (which is how I know what little I know about
> replication since I was involved in a project to do this in the early 1990s
> before the whole db replication thing got so commonplace) the word
> replication means not that anything was done more than once, but that the
> one result was propagated to multiple places. So it seems to me replication
> is about multiple result instances, not multiple action instances.
>
> --
> _ _
> ._ _ _ <_> ___ _ _ ___ ___ ___ _| | ___
> | ' ' || |/ | '| '_>/ . \/ | '/ . \/ . |/ ._>
> |_|_|_||_|\_|_.|_| \___/\_|_.\___/\___|\___.
>
>
> ___
> fpc-pascal maillist - fpc-pascal@lists.freepascal.org
> http://lists.freepascal.org/mailman/listinfo/fpc-pascal
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] linux: should we hard-code versioned or unversioned shared libraries in our apps?
Hi, This issue has come up before in a fcl-db discussion regarding the Firebird Database, where the libfbclient.so was missing from many Linux distros (eg: Ubuntu 10.04), but a libfbclient.so.2.0 was available instead. FCL-DB only checks for the unversioned shared libraries, thus your application will probably not run out of the box. I've stumbled across this problem again today with OpenSUSE 12.1 and Synapse where I send emails from inside my applications via a secure SMTP connection. The Synapse library is looking for libssl.so, but by default OpenSUSE only has libssl.so.1.0.0. In both these cases, I manually created unversioned symlinks to those libraries, and that got my applications working again. This is not ideal, but I don't know how else to handle this. Does any body know what is the "most correct" way of handling this? Am I supposed to modify my copies of fcl-db and synapse to look for specific versions of these shared libraries, or should I somehow add a function in my application installation that checks in unversioned shared libraries exist, and if not, try and create those (which would require root access - and might cause problems an client installs). Anybody know of any Linux documentation URL that explain when unversioned shared libraries are used and when not, and how applications are supposed to handle this? -- Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://fpgui.sourceforge.net ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: Get all caller adresses of a given function/procedure before executing
Am Wednesday 15 August 2012 12:29:23 schrieb Jorge Aldo G. de F. Junior: > "And a > disadvantage is may the longer time to find a solution." > > Thats not the only disadvantage. Reinventing the wheel usually means > you get something less correct and less researched. Its simple, 1000 > eyes looking for a bug into a standard library will spot much more > problems than your lone eye looking for a bug into your own > implementation. My programs are bugfree :-) Seriously: I feel ok with my style of programming. If you take a (standard) library it does not mean that everything is solved and that there are no questions as you can read in the many threads here in the mailinglist. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] linux: should we hard-code versioned or unversioned shared libraries in our apps?
But creating correct symlinks IS one of the tasks of a system administrator... His up to know the distro he is using and the software he wants to install. I bet a "in the field" sysadmin will be much more flexible than a hardcoded implementation that would need to take zillions of obscure distros in consideration from the limited perspective of compile time... 2012/8/15 Graeme Geldenhuys : > Hi, > > This issue has come up before in a fcl-db discussion regarding the > Firebird Database, where the libfbclient.so was missing from many > Linux distros (eg: Ubuntu 10.04), but a libfbclient.so.2.0 was > available instead. FCL-DB only checks for the unversioned shared > libraries, thus your application will probably not run out of the box. > > I've stumbled across this problem again today with OpenSUSE 12.1 and > Synapse where I send emails from inside my applications via a secure > SMTP connection. The Synapse library is looking for libssl.so, but by > default OpenSUSE only has libssl.so.1.0.0. > > In both these cases, I manually created unversioned symlinks to those > libraries, and that got my applications working again. This is not > ideal, but I don't know how else to handle this. > > Does any body know what is the "most correct" way of handling this? Am > I supposed to modify my copies of fcl-db and synapse to look for > specific versions of these shared libraries, or should I somehow add > a function in my application installation that checks in unversioned > shared libraries exist, and if not, try and create those (which would > require root access - and might cause problems an client installs). > > Anybody know of any Linux documentation URL that explain when > unversioned shared libraries are used and when not, and how > applications are supposed to handle this? > > -- > Regards, > - Graeme - > > > ___ > fpGUI - a cross-platform Free Pascal GUI toolkit > http://fpgui.sourceforge.net > ___ > fpc-pascal maillist - fpc-pascal@lists.freepascal.org > http://lists.freepascal.org/mailman/listinfo/fpc-pascal ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] linux: should we hard-code versioned or unversioned shared libraries in our apps?
On 15 Aug 2012, at 12:43, Graeme Geldenhuys wrote: > This issue has come up before in a fcl-db discussion regarding the > Firebird Database, where the libfbclient.so was missing from many > Linux distros (eg: Ubuntu 10.04), but a libfbclient.so.2.0 was > available instead. FCL-DB only checks for the unversioned shared > libraries, thus your application will probably not run out of the box. > > In both these cases, I manually created unversioned symlinks to those > libraries, and that got my applications working again. This is not > ideal, but I don't know how else to handle this. The official way to get the unversioned symbolic links is to install the -dev or -devel package for that library. Of course, you're not supposed to require end-users to do that. > Does any body know what is the "most correct" way of handling this? Determine which major version of the library you require (e.g. 1.x, or 2.x, or even something like 5.1.x if the library in question only supports API compatibility across minor releases), and explicitly load that one. That is also how it works when linking against a library at compile time: the unversioned name is simply a symbolic link to a versioned file name, and it's that versioned file name that the linker will hardcode in your application. The reasoning is that your application was written and tested against that version of the library, so letting it use arbitrary other versions is not a good idea. If you can work with multiple major versions, you can try to dynamically load them all until you have found one that exists. At least most (if not all) FCL units that dynamically load libraries have a function that you can call to explicitly specify the name of the dynamic library to use. Since the units themselves have presumably been written to work with certain versions of those libraries, it would however probably be best if that code were directly added to those units (and to remove any *default* dynamic loading of unversioned file names, since such libraries usually only exist on a developer's machine -- except maybe on non-Unix platforms). Jonas___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Don't understand Zipper.DoEndOfFile/UnZipper.DoEndOfFile
I've been working on documenting the Zipper/Unzipper classes: packages\paszlib\src\zipper.pp Now looking at the protected procedure TZipper/TUnzipper.DoEndOfFile They apparently update compression percentage statistics and call a user defined callback (if any, defined in OnEndOfFile) I don't understand though by whom/if they are called? A grep through the source code showed nothing referencing it. Thanks, Reinier ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] linux: should we hard-code versioned or unversioned shared libraries in our apps?
Graeme Geldenhuys wrote: Hi, This issue has come up before in a fcl-db discussion regarding the Firebird Database, where the libfbclient.so was missing from many Linux distros (eg: Ubuntu 10.04), but a libfbclient.so.2.0 was available instead. FCL-DB only checks for the unversioned shared libraries, thus your application will probably not run out of the box. I've stumbled across this problem again today with OpenSUSE 12.1 and Synapse where I send emails from inside my applications via a secure SMTP connection. The Synapse library is looking for libssl.so, but by default OpenSUSE only has libssl.so.1.0.0. In both these cases, I manually created unversioned symlinks to those libraries, and that got my applications working again. This is not ideal, but I don't know how else to handle this. Quite a long way from ideal, since it implies that an administrator has to be involved even if the program is only sitting in an unprivileged user's home directory (or is a symlink in ~ good enough?). I'm tempted to say that this is a distro issue, and that if an upstream project (FireBird, OpenSSL, PostgreSQL) normally publishes an unversioned library that a distro is at fault if it "decorates" it with an appended version number without providing a symlink chain. I'd suggest that the best solution would be for FPC policy to mandate that all shared library (.so etc.) usage in the RTL/FCL/LCL should be capable of taking a library name parameter, and for application code to allow this name to be specified in a .ini file. I think this would be safer than having the app try to deduce the location of the appropriate file, since sooner or later there will be a case where it sees multiple versions and selects the wrong one, or assumes that e.g. /usr/local/opt is permanently available when in fact it's a short-term NFS mount. And doing it that way means that the user would be aware of the problem, and if enough users are aware of the problem it might trickle through to the awareness of the distreaux maintainers. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] linux: should we hard-code versioned or unversioned shared libraries in our apps?
Hi, On 15 August 2012 12:10, Jonas Maebe wrote: > > The official way to get the unversioned symbolic links is to install the -dev > or > -devel package for that library. Of course, you're not supposed to require > end-users to do that. Yes, I know that bit, but even as a developer, if I don't do actual Firebird or OpenSSL development (I don't work on those project, I simply use there libraries), I don't need to install those libraries. That is why my Ubuntu and OpenSUSE system didn't have the -devel packages for them installed. FCL-db and Synapse dynamically load those libraries on my development machines, so no -devel package requirement. > ... that the linker will hardcode in your application. The reasoning is that > your > application was written and tested against that version of the library, so > letting > it use arbitrary other versions is not a good idea. In a way I understand the reasoning for the unversioned symlink, I just don't know how best to handle it in my apps. I also don't know the rules as to which version the unversioned symlib will normally point to.I know my apps work with Firebird 2.1 and Firebird 2.5, so should I then change fcl-db to look for libfbclient.so.2 or libfbclient.so.2.0 - instead of the unversioned default. Because the unversioned default could very easily point to a v1.x library of Firebird, and that would be untested with my app (it will probably not work). > If you can work with multiple major versions, you can try to dynamically > load them all until you have found one that exists. OK, I'll take a look at this idea. That seems better, because then I know I am trying to load library versions my app is known to work with. I'm not so much concerned about my development system (I can fix that) - I am thinking more in line of when I deploy my apps. I want them to obviously work as easily as possible. -- Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://fpgui.sourceforge.net ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] linux: should we hard-code versioned or unversioned shared libraries in our apps?
Jonas Maebe wrote: In both these cases, I manually created unversioned symlinks to those libraries, and that got my applications working again. This is not ideal, but I don't know how else to handle this. The official way to get the unversioned symbolic links is to install the -dev or -devel package for that library. Of course, you're not supposed to require end-users to do that. Does not always work, e.g. in the case of Debian. -dev will install the .h and .a files, but won't necessarily set up unversioned symlinks. Anybody: what's the position with Ubuntu, as the leading Debian derivative? -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: Get all caller adresses of a given function/procedure before executing
In our previous episode, Rainer Stratmann said: > > You already have a very good grasp of the issues involved as you were > > writing your own solution. You could probably improve dxgettext with > > some things and get that in the main development tree, thereby improving > > things for others. > > As I read now here > http://dxgettext.po.dk/ > gettext seems already to be a (very) good solution. I am wondering why there > are some problems with as I read somewhere in this thread. Limitations, not problems. Compared to the Delphi internal translation systems. Yours has the same, by design. Note that I think dxgettext is a netto plus compared to ITE. If your source (main) language has a word with two meanings, how will you translate to a language where there is a word for each meaning? IIRC dxgettext has only solutions for that when you recognize this early and add special code. This means that sometimes you can't simply ship a translation, but also have to (dx)gettext also has support for stuff like multiples, textdomains. Some of it is not very well supported in the editor (gorm) though. > For me it would be interesting to know how dxgettext gets the snippet > information from the program code...! It comes with source scanner tools to harvest strings from the code. The source for this + the editor are available. Most will readily work with FPC/Lazarus, except maybe unicode issues. What's your unicode philosophy btw? ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] linux: should we hard-code versioned or unversioned shared libraries in our apps?
Hi, On 15 August 2012 12:27, Mark Morgan Lloyd wrote: > Quite a long way from ideal, since it implies that an administrator has to > be involved even if the program is only sitting in an unprivileged user's > home directory (or is a symlink in ~ good enough?). Correct, definitely not ideal. I was just thinking about the $HOME directory. I'll try and play with that now, and see what happens to my apps. Maybe my apps should all have startup scripts that define local LD_LIBRARY_PATH options? > I'm tempted to say that this is a distro issue, and that if an upstream > project (FireBird, OpenSSL, PostgreSQL) normally publishes an unversioned > library that a distro is at fault if it "decorates" it with an appended > version number without providing a symlink chain. They explicitly mention that general runtime libraries should not include the unversioned symlink. Only the -devel packages should include those. That makes me think, why do we then need the unversioned symlink in the first place! Fedora: http://fedoraproject.org/wiki/Packaging:Guidelines#Devel_Packages OpenSUSE: http://en.opensuse.org/openSUSE:Shared_library_packaging_policy#Unversioned_packages Ubuntu/Debian: ?? I can't remember the URL now. -- Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://fpgui.sourceforge.net ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] linux: should we hard-code versioned or unversioned shared libraries in our apps?
On 15/08/12 12:37, Mark Morgan Lloyd wrote: > Jonas Maebe wrote: > >>> In both these cases, I manually created unversioned symlinks to those >>> libraries, and that got my applications working again. This is not >>> ideal, but I don't know how else to handle this. >> >> The official way to get the unversioned symbolic links is to install >> the -dev or -devel package for that library. Of course, you're not >> supposed to require end-users to do that. > > Does not always work, e.g. in the case of Debian. -dev will install the > .h and .a files, but won't necessarily set up unversioned symlinks. I've never found a -dev package that doesn't set up symlinks in many years of using Debian for development. (Except if only static versions of a specific library exists, obviously). Could you give an example? Henry ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Don't understand Zipper.DoEndOfFile/UnZipper.DoEndOfFile
On Wed, 15 Aug 2012, Reinier Olislagers wrote: I've been working on documenting the Zipper/Unzipper classes: packages\paszlib\src\zipper.pp Now looking at the protected procedure TZipper/TUnzipper.DoEndOfFile They apparently update compression percentage statistics and call a user defined callback (if any, defined in OnEndOfFile) I don't understand though by whom/if they are called? A grep through the source code showed nothing referencing it. The calls to these routines must have fallen out during some refactoring. They should be called when the zip/unzip operation is done. Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] linux: should we hard-code versioned or unversioned shared libraries in our apps?
On 15 Aug 2012, at 13:32, Graeme Geldenhuys wrote: > On 15 August 2012 12:10, Jonas Maebe wrote: >> >> The official way to get the unversioned symbolic links is to install the >> -dev or >> -devel package for that library. Of course, you're not supposed to require >> end-users to do that. > > Yes, I know that bit, but even as a developer, if I don't do actual > Firebird or OpenSSL development (I don't work on those project, I > simply use there libraries), I don't need to install those libraries. The dev/devel packages are not for people working on those libraries, they are for building programs that use those libraries. It's developers that do work on those packages themselves that don't necessarily need those packages, since they can just use their own source code. > That is why my Ubuntu and OpenSUSE system didn't have the -devel > packages for them installed. FCL-db and Synapse dynamically load those > libraries on my development machines, so no -devel package > requirement. You said that you manually created the symbolic link. I simply explained that you should never do that, and instead install the development packages because they will do that (correctly) for you. Whether or not it is desirable for the FCL/Synapse units to require an unversioned symlink to be present is a separate issue. >> ... that the linker will hardcode in your application. The reasoning is that >> your >> application was written and tested against that version of the library, so >> letting >> it use arbitrary other versions is not a good idea. > > In a way I understand the reasoning for the unversioned symlink, I > just don't know how best to handle it in my apps. I also don't know > the rules as to which version the unversioned symlib will normally > point to. It will point to the library of the version corresponding to the dev/devel package that has been installed. > I know my apps work with Firebird 2.1 and Firebird 2.5, so > should I then change fcl-db to look for libfbclient.so.2 or > libfbclient.so.2.0 - instead of the unversioned default. libfbclient.so.2.0 means Firebird 2.0.x. libfbclient.so.2 means Firebird 2.x. If you only support 2.1 and 2.5, you should link against libfbclient.so.2 and then call a function to get the actual version. If the library does not contain such a function, then there is simply no way to dynamically load that library and use it in a safe way in your scenario. Jonas___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Don't understand Zipper.DoEndOfFile/UnZipper.DoEndOfFile
On 15-8-2012 13:48, Michael Van Canneyt wrote: > On Wed, 15 Aug 2012, Reinier Olislagers wrote: > >> I've been working on documenting the Zipper/Unzipper classes: >> packages\paszlib\src\zipper.pp >> Now looking at the protected procedure TZipper/TUnzipper.DoEndOfFile >> >> They apparently update compression percentage statistics and call a user >> defined callback (if any, defined in OnEndOfFile) >> >> I don't understand though by whom/if they are called? A grep through the >> source code showed nothing referencing it. > > The calls to these routines must have fallen out during some > refactoring. They should be called when the zip/unzip operation is done. Ok, just for confirmation: done after each file in the list - as oppposed to the zip/unzip operation on the entire zip file, right? I'll have a look through the history to see if I can find it and write up a patch. Thanks, Reinier ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: Get all caller adresses of a given function/procedure before executing
Am Wednesday 15 August 2012 13:39:11 schrieb Marco van de Voort: > In our previous episode, Rainer Stratmann said: > > > You already have a very good grasp of the issues involved as you were > > > writing your own solution. You could probably improve dxgettext with > > > some things and get that in the main development tree, thereby > > > improving things for others. > > > > As I read now here > > http://dxgettext.po.dk/ > > gettext seems already to be a (very) good solution. I am wondering why > > there are some problems with as I read somewhere in this thread. > > Limitations, not problems. Compared to the Delphi internal translation > systems. Yours has the same, by design. Which limitations? > Note that I think dxgettext is a netto plus compared to ITE. I do not understand what you mean here. > If your source (main) language has a word with two meanings, how will you > translate to a language where there is a word for each meaning? You mean 2 words spread over the program? Then I can put an additional identifier like already mentioned. ls( '~ID1~word' ); ls( '~ID2~word' ); In this case ID1 or ID2 is the identifier instead of 'word'. But in all cases 'word' is the result of the translation of the original language. > IIRC dxgettext has only solutions for that when you recognize this early > and add special code. This means that sometimes you can't simply ship a > translation, but also have to In my case it can also be possible that there are not all words translated yet. Then the original text is shown or englich one. The translation can be made later. That is (also) an advantage. > (dx)gettext also has support for stuff like multiples, textdomains. Some of > it is not very well supported in the editor (gorm) though. I will use a browser as editor. So the utf8 (and unicode?) converting is made automatically by the browser. I have some code for converting ascii <-> utf8. > > For me it would be interesting to know how dxgettext gets the snippet > > information from the program code...! > > It comes with source scanner tools to harvest strings from the code. Another step more that means more work and less easiness (less userfriendly). > The source for this + the editor are available. Most will readily work with > FPC/Lazarus, except maybe unicode issues. > > What's your unicode philosophy btw? I need a converter from ascii to unicode. Then the browser can show this I think. With uft8 it works already. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: Get all caller adresses of a given function/procedure before executing
Am 15.08.2012 10:48 schrieb "Rainer Stratmann" : > > While this may all be very well known to you, I would ask you to step > > back and consider it: having a detached look at it may lead to a better > > choice. > > For me it would be interesting to know how dxgettext gets the snippet > information from the program code...! It scans the source beforehand and looks for resourcestrings and additionally for string constants embedded in a function call to "_()" (which is their translation function). It also allows to scan DFM files. Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Don't understand Zipper.DoEndOfFile/UnZipper.DoEndOfFile
On Wed, 15 Aug 2012, Reinier Olislagers wrote: On 15-8-2012 13:48, Michael Van Canneyt wrote: On Wed, 15 Aug 2012, Reinier Olislagers wrote: I've been working on documenting the Zipper/Unzipper classes: packages\paszlib\src\zipper.pp Now looking at the protected procedure TZipper/TUnzipper.DoEndOfFile They apparently update compression percentage statistics and call a user defined callback (if any, defined in OnEndOfFile) I don't understand though by whom/if they are called? A grep through the source code showed nothing referencing it. The calls to these routines must have fallen out during some refactoring. They should be called when the zip/unzip operation is done. Ok, just for confirmation: done after each file in the list - as oppposed to the zip/unzip operation on the entire zip file, right? Yes. I'll have a look through the history to see if I can find it and write up a patch. That would be nice :) Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] linux: should we hard-code versioned or unversioned shared libraries in our apps?
Henry Vermaak wrote: On 15/08/12 12:37, Mark Morgan Lloyd wrote: Jonas Maebe wrote: In both these cases, I manually created unversioned symlinks to those libraries, and that got my applications working again. This is not ideal, but I don't know how else to handle this. The official way to get the unversioned symbolic links is to install the -dev or -devel package for that library. Of course, you're not supposed to require end-users to do that. Does not always work, e.g. in the case of Debian. -dev will install the .h and .a files, but won't necessarily set up unversioned symlinks. I've never found a -dev package that doesn't set up symlinks in many years of using Debian for development. (Except if only static versions of a specific library exists, obviously). Could you give an example? [Checks a couple of systems] I can't be /absolutely/ certain without building a system from clean, but the thing that regularly bites me is the PostgreSQL client library and I've recently been bitten by libcap2. However, I suspect that in both cases I might have set up a symlink myself and later installed the -dev package, I don't have an easy way of reconciling usage of ln -s (logged in root's .bash_history) with the date a package was installed (which I log into RCS). So I might have to recant, or to deprecate my testimony as unreliable :-) I do agree with Graeme's position though: a -dev is described as containing files for developers, and it should not be necessary for a non-developer user to start encumbering his system with .h files etc. What's more, part of the reason that I've had to create symlinks manually in the past is because things like (if I recall correctly) OpenOffice's interface to PostgreSQL require libpq.so without declaring -dev as a prerequisite... which rather reinforces my position that this is a distro issue even if they prefer to disclaim it. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Re: linux: should we hard-code versioned or unversioned shared libraries in our apps?
On 15-8-2012 13:49, Jonas Maebe wrote: > > On 15 Aug 2012, at 13:32, Graeme Geldenhuys wrote: > >> On 15 August 2012 12:10, Jonas Maebe >> wrote: >>> >>> The official way to get the unversioned symbolic links is to install the >>> -dev or >>> -devel package for that library. Of course, you're not supposed to require >>> end-users to do that. >> >> Yes, I know that bit, but even as a developer, if I don't do actual >> Firebird or OpenSSL development (I don't work on those project, I >> simply use there libraries), I don't need to install those libraries. > > The dev/devel packages are not for people working on those libraries, they > are for building programs that use those libraries. It's developers that do > work on those packages themselves that don't necessarily need those packages, > since they can just use their own source code. > >> That is why my Ubuntu and OpenSUSE system didn't have the -devel >> packages for them installed. FCL-db and Synapse dynamically load those >> libraries on my development machines, so no -devel package >> requirement. > > You said that you manually created the symbolic link. I simply explained that > you should never do that, and instead install the development packages > because they will do that (correctly) for you. Whether or not it is desirable > for the FCL/Synapse units to require an unversioned symlink to be present is > a separate issue. In other words, you'd have to add the relevant -dev/-devel packages as dependencies in your .deb or .rpm package, right? ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: Get all caller adresses of a given function/procedure before executing
Am Wednesday 15 August 2012 14:13:41 schrieb Sven Barth: > Am 15.08.2012 10:48 schrieb "Rainer Stratmann" > > > While this may all be very well known to you, I would ask you to step > > > back and consider it: having a detached look at it may lead to a better > > > choice. > > > > For me it would be interesting to know how dxgettext gets the snippet > > information from the program code...! > > It scans the source beforehand and looks for resourcestrings and > additionally for string constants embedded in a function call to "_()" > (which is their translation function). It also allows to scan DFM files. If the compiler would simply store the 2 informations (caller adress, pointer to the pchar) in a list this scan beforehand would not be necessary anymore like in my solution. I would call this function rs( s : pchar ) because it has to be short. if there is a rs() in the program the compiler stores the caller adress (unique handle) and the pointer to the pchar in a list. That would be an advantage for freepascal if providing this information native and not by some kind of hack like I do now. Then also the compatible/portable discussion would have an end. And the jokes about try to make it more difficult to search through the opcodes :-) ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: Get all caller adresses of a given function/procedure before executing
Am Wednesday 15 August 2012 14:49:04 schrieb Rainer Stratmann: > I would call this function rs( s : pchar ) because it has to be short. > if there is a rs() in the program the compiler stores the caller adress > (unique handle) and the pointer to the pchar in a list. If the pointer to pchar is unique then this one information will be already enough. That means the parameter s must be a constant text. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] linux: should we hard-code versioned or unversioned shared libraries in our apps?
Hi, On 15 August 2012 12:49, Jonas Maebe wrote: > You said that you manually created the symbolic link. I simply explained that > you should > never do that, and instead install the development packages because they will > do that > (correctly) for you. So my applications that I deploy to clients will now require -devel packages? This just doesn't sound sane, sorry. Maybe there is just a fundamental flaw in all distros and how they package software. Initially a great idea (in theory), but in reality it is seriously flawed. > Whether or not it is desirable for the FCL/Synapse units to require an > unversioned > symlink to be present is a separate issue. FCL-DB uses dynamic linking by default, and looks for the unversioned shared library. So what specific Firebird version is the FCL-DB coded too? Because remember, libfbclient.so can point to a v1.x or a v2.x - depending on what -devel package was installed. This uncertain (version mismatch) is what I would like to avoid, plus the fact that my clients now need to install -devel packages too. Maybe I should simply install my apps into /home//. My installer would then ship the required/expected *.so files, and setup the unversioned symlink. My app would then be launched via a script which sets the LD_LIBRARY_PATH to the application directory. My app would then be totally self-contained. This seems like the only way to get around these flawed package management rules and dependencies. > It will point to the library of the version corresponding to the dev/devel > package that has been installed. So one minute it could point to a v1.x library, and the next it could point to a v2.x library. This will surely break many apps that only look at the unversioned symlink. > libfbclient.so.2.0 means Firebird 2.0.x. libfbclient.so.2 means Firebird 2.x. OK, thanks for that. My apps are tiOPF based, and tiOPF uses the bare minimum functionality from each backend database server. Basically just the CRUD (create, read, update and delete) functions. So even though I say our apps use Firebird DB v2.x, it will most probably run on a v1.x system too, but like I said, that would be untested. We only test with v2.x Firebird servers. -- Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://fpgui.sourceforge.net ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Re: Get all caller adresses of a given function/procedure before executing
On 15/08/2012 13:55, Rainer Stratmann wrote: > Am Wednesday 15 August 2012 14:49:04 schrieb Rainer Stratmann: >> I would call this function rs( s : pchar ) because it has to be short. >> if there is a rs() in the program the compiler stores the caller adress >> (unique handle) and the pointer to the pchar in a list. > > If the pointer to pchar is unique then this one information will be already > enough. That means the parameter s must be a constant text. This question has long lingered in my brain just could not express it: What happens in your program/translator, if the strings change their physical/relative address? For example if you add/remove units and rebuild. For example if FPC internals decide to add or remove some padding in front of the constants. Will all your translation work go to waste ? L. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] linux: should we hard-code versioned or unversioned shared libraries in our apps?
On 15/08/12 13:43, Mark Morgan Lloyd wrote:
>
> I do agree with Graeme's position though: a -dev is described as
> containing files for developers, and it should not be necessary for a
> non-developer user to start encumbering his system with .h files etc.
> What's more, part of the reason that I've had to create symlinks
> manually in the past is because things like (if I recall correctly)
> OpenOffice's interface to PostgreSQL require libpq.so without declaring
> -dev as a prerequisite... which rather reinforces my position that this
> is a distro issue even if they prefer to disclaim it.
I'd say that it's the OpenOffice interface that's broken. They
shouldn't link to a library that doesn't specify a version. They need
to link to a specific version by using the naming conventions as Jonas
explained. This is to protect yourself from api/feature breakage.
Linking directly to, e.g. libpq.so, is only o.k. if you can check the
version by means of some api, which the library needs to supply in all
the versions that exist - past, present and future. Which is probably
what they're doing. This isn't very good practice, in my opinion, but
can work.
If they really support multiple versions of libpq, then they will have
to try to dynamically link against all the versions they support. This
won't be much more effort than checking the version in the first place.
Even on Windows some libraries are using names that reflect the version,
e.g. I link to some opencv libs, which are named
libopencv_{module}231.dll. I suspect this is much less of a problem in
the Windows world, since library reuse isn't that common.
Henry
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] linux: should we hard-code versioned or unversioned shared libraries in our apps?
On 15 Aug 2012, at 15:14, Graeme Geldenhuys wrote: > On 15 August 2012 12:49, Jonas Maebe wrote: >> You said that you manually created the symbolic link. I simply explained >> that you should >> never do that, and instead install the development packages because they >> will do that >> (correctly) for you. > > So my applications that I deploy to clients will now require -devel > packages? They always have required them until now (as have any other applications that use fcl-db). > This just doesn't sound sane, sorry. Maybe there is just a > fundamental flaw in all distros and how they package software. > Initially a great idea (in theory), but in reality it is seriously > flawed. It's the fcl-db/Synapse units that are flawed. As explained in my first reply, the unversioned symlink is only for use by the linker (ld), and they work perfectly well for that purpose. >> Whether or not it is desirable for the FCL/Synapse units to require an >> unversioned >> symlink to be present is a separate issue. > > FCL-DB uses dynamic linking by default, and looks for the unversioned > shared library. So what specific Firebird version is the FCL-DB coded > too? I have no idea, which is why I also said in my first reply: *** At least most (if not all) fcl units that dynamically load libraries have a function that you can call to explicitly specify the name of the dynamic library to use. Since the units themselves have presumably been written to work with certain versions of those libraries, it would however probably be best if that code were directly added to those units (and to remove any *default* dynamic loading of unversioned file names, since such libraries usually only exist on a developer's machine -- except maybe on non-Unix platforms). *** > Maybe I should simply install my apps into /home//. My > installer would then ship the required/expected *.so files, and setup > the unversioned symlink. My app would then be launched via a script > which sets the LD_LIBRARY_PATH to the application directory. My app > would then be totally self-contained. This seems like the only way to > get around these flawed package management rules and dependencies. While shipping all libraries yourself is an option, the package management rules and dependencies are not flawed (or at least the scenario you are describing currently does not point to a flaw in them). If you start shipping libraries yourself, you'd better make sure that you also ship all libraries they in turn depend on as well, because otherwise you're more likely to make the problem worse than solve it. >> It will point to the library of the version corresponding to the dev/devel >> package that has been installed. > > So one minute it could point to a v1.x library, and the next it could > point to a v2.x library. This will surely break many apps that only > look at the unversioned symlink. As mentioned in my previous replies, applications should never look at the unversioned link in the first place when dynamically loading a library. Jonas___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] linux: should we hard-code versioned or unversioned shared libraries in our apps?
In our previous episode, Graeme Geldenhuys said:
> In both these cases, I manually created unversioned symlinks to those
> libraries, and that got my applications working again. This is not
> ideal, but I don't know how else to handle this.
> Does any body know what is the "most correct" way of handling this?
(1) avoid _dyn versions.
(2) override the built-in naming by calling
ibase60dyn.initializeibase60('whatever.so');
before connection or other db parts initializes.
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] linux: should we hard-code versioned or unversioned shared libraries in our apps?
In our previous episode, Graeme Geldenhuys said: > > You said that you manually created the symbolic link. I simply explained > > that you should > > never do that, and instead install the development packages because they > > will do that > > (correctly) for you. > > So my applications that I deploy to clients will now require -devel > packages? This just doesn't sound sane, sorry. Maybe there is just a > fundamental flaw in all distros and how they package software. No. It all works fine WITHIN a distribution (in a particular version). And basically that is the only supported way on Linux. Anything crossdistribution and cross-distroversion is assumed to be on source level, not binary level (IOW rebuild your app). According to common linux philosophy distributing crossdistro binaries is asking for pain. Basically if you link to a .so the normal way, to simplify build systems, a symlink from a generic name to a versioned name is used. But the generic binary contains a reference to the versioned name, and thus will work without symlink, which is why end-users systems don't have the link. But this way of linking is more dependent on the exact version of the library, so in the past some people changed everything to dynamically loaded via dlload/dlsym. This alleviates the versioning problem somewhat, but discards the only distribution provided way to fix this. I still think that changing everything to _dyn created more problems than it solved. (except for special disaster case mysql maybe) ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] linux: should we hard-code versioned or unversioned shared libraries in our apps?
Hi, On 15 August 2012 14:39, Jonas Maebe wrote: >> FCL-DB uses dynamic linking by default, and looks for the unversioned >> shared library. So what specific Firebird version is the FCL-DB coded >> too? > > I have no idea, which is why I also said in my first reply: Umm, so ideally the ibconnection.pp unit should really be split into various units with version numbers in their names. That way we will know to which Firebird version they are referring too. eg: ibconnection.pp // old interbase only (eg: Delphi 7) firebird-1.x.pp firebird-2.1.pp firebird-2.5.pp Include files could probably be used to reduce some duplication of code. > As mentioned in my previous replies, applications should never look at the > unversioned link in the first place when dynamically loading a library. OK, for now I'll modify my fcl-db and synapse code to look for the versioned shared libraries that I know I have tested with. eg: libfbclient.so.2 Thanks for all the help guys. -- Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://fpgui.sourceforge.net ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Re: linux: should we hard-code versioned or unversioned shared libraries in our apps?
On 15-8-2012 15:59, Graeme Geldenhuys wrote: > Hi, > > On 15 August 2012 14:39, Jonas Maebe > wrote: >>> FCL-DB uses dynamic linking by default, and looks for the unversioned >>> shared library. So what specific Firebird version is the FCL-DB coded >>> too? >> >> I have no idea, which is why I also said in my first reply: > > Umm, so ideally the ibconnection.pp unit should really be split into > various units with version numbers in their names. That way we will > know to which Firebird version they are referring too. > > eg: ibconnection.pp // old interbase only (eg: Delphi 7) > firebird-1.x.pp > firebird-2.1.pp > firebird-2.5.pp > > Include files could probably be used to reduce some duplication of code. OT: that would be useful for another reason. Firebird 3 will introduce the BOOLEAN datatype and other innovations (encrypted connections, etc). Interbase has had BOOLEAN support for a while now. It would be nice to be able to support new functionality without sacrificing the ability to connect to older clients. Of course, this has an obvious parallel to the mysql45...6 units; sorry that I don't know how things are handled there; I've stayed away from them as much as possible... ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: Get all caller adresses of a given function/procedure before executing
Am Wednesday 15 August 2012 15:20:21 schrieb Lukasz Sokol: > On 15/08/2012 13:55, Rainer Stratmann wrote: > > Am Wednesday 15 August 2012 14:49:04 schrieb Rainer Stratmann: > >> I would call this function rs( s : pchar ) because it has to be short. > >> if there is a rs() in the program the compiler stores the caller adress > >> (unique handle) and the pointer to the pchar in a list. > > > > If the pointer to pchar is unique then this one information will be > > already enough. That means the parameter s must be a constant text. > > This question has long lingered in my brain just could not express it: > > What happens in your program/translator, if the strings change their > physical/relative address? Then the mov pcharconst , EAX command also had changed. At every start of the program I see if it works here. If it works here ist works outside also. > For example if you add/remove units and rebuild. All pchar adresses are searched at programstart. > For example if FPC internals decide to add or remove some padding in front > of the constants. Very unlikely. For which reason should there be padding in front? I can not see any insolvable problem here. > Will all your translation work go to waste ? Then I would have a look at the opcodes directly and see what has been changed and likely find a solution. If the maintainers decide to build in the suggested function above then everthing is solved. By now no one of the maintainers wants this. I also can ask what happens if there are no more maintainers for fpc? ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: Get all caller adresses of a given function/procedure before executing
In our previous episode, Rainer Stratmann said: > > Limitations, not problems. Compared to the Delphi internal translation > > systems. Yours has the same, by design. > > Which limitations? see below > > If your source (main) language has a word with two meanings, how will you > > translate to a language where there is a word for each meaning? > > You mean 2 words spread over the program? yes. > Then I can put an additional identifier like already mentioned. > ls( '~ID1~word' ); > ls( '~ID2~word' ); > In this case ID1 or ID2 is the identifier instead of 'word'. > But in all cases 'word' is the result of the translation of the original > language. > > > IIRC dxgettext has only solutions for that when you recognize this early > > and add special code. This means that sometimes you can't simply ship a > > translation, but also have to > > In my case it can also be possible that there are not all words translated > yet. Then the original text is shown or englich one. The translation can be > made later. That is (also) an advantage. No it can't, since if two the same texts translate to a different texts in another language, you need to add the identifiers and rebuild, distribute/migrate etc. ITE doesn't have this limitation, since the fully qualified identifier is what uniquely identifies the text, not the content. The editor has some features so that you don't have to translate something as "settings" twice. Moreover, ITE support widening and moving of components. (essentially anything published in forms is editable without recompilation) > > (dx)gettext also has support for stuff like multiples, textdomains. Some of > > it is not very well supported in the editor (gorm) though. > > I will use a browser as editor. So the utf8 (and unicode?) converting is > made automatically by the browser. I have some code for converting ascii > <-> utf8. What do you assume about the codepage of literals? Do you pass the right -Fc parameters for that? > > It comes with source scanner tools to harvest strings from the code. > > Another step more that means more work and less easiness (less > userfriendly). Explain. You need to scan some way too. How do you handle combining translations btw? (e.g. general framework and customer specific part on top of that?) ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: linux: should we hard-code versioned or unversioned shared libraries in our apps?
On Wed, 15 Aug 2012, Reinier Olislagers wrote: On 15-8-2012 15:59, Graeme Geldenhuys wrote: Hi, On 15 August 2012 14:39, Jonas Maebe wrote: FCL-DB uses dynamic linking by default, and looks for the unversioned shared library. So what specific Firebird version is the FCL-DB coded too? I have no idea, which is why I also said in my first reply: Umm, so ideally the ibconnection.pp unit should really be split into various units with version numbers in their names. That way we will know to which Firebird version they are referring too. eg: ibconnection.pp // old interbase only (eg: Delphi 7) firebird-1.x.pp firebird-2.1.pp firebird-2.5.pp Include files could probably be used to reduce some duplication of code. OT: that would be useful for another reason. Firebird 3 will introduce the BOOLEAN datatype and other innovations (encrypted connections, etc). Interbase has had BOOLEAN support for a while now. It would be nice to be able to support new functionality without sacrificing the ability to connect to older clients. That has nothing to do with dyn versus static linking. You can perfectly detect which library version you are loading, and enable/disable certain functions based on this. Mysql is a different story in that the internals of the structures change with each release, making it almost impossible to unite all versions in 1 unit. Firebird has a long tradition of keeping the API and structures backwards/forwards compatible, thus obliviating the need for different units for each version. Conclusion: At least for firebird, there will be 1 unit, loading dynamically what is available. If you want to load something else than the default, you have been able to do so since day 1. Contrary to Marco's belief, I am firmly convinced that this is the best and easiest approach. Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: linux: should we hard-code versioned or unversioned shared libraries in our apps?
On 15-8-2012 16:19, Michael Van Canneyt wrote: > On Wed, 15 Aug 2012, Reinier Olislagers wrote: >> On 15-8-2012 15:59, Graeme Geldenhuys wrote: >>> Umm, so ideally the ibconnection.pp unit should really be split into >>> various units with version numbers in their names. That way we will >>> know to which Firebird version they are referring too. >>> >>> eg: ibconnection.pp // old interbase only (eg: Delphi 7) >>> firebird-1.x.pp >>> firebird-2.1.pp >>> firebird-2.5.pp >>> >>> Include files could probably be used to reduce some duplication of code. >> OT: that would be useful for another reason. >> Firebird 3 will introduce the BOOLEAN datatype and other innovations >> (encrypted connections, etc). >> Interbase has had BOOLEAN support for a while now. >> >> It would be nice to be able to support new functionality without >> sacrificing the ability to connect to older clients. > > That has nothing to do with dyn versus static linking. Yes, that's why I mentioned it's OT ;) > You can perfectly detect which library version you are loading, and > enable/disable certain functions based on this. Ok. And you can use the (Firebird/Interbase Services IIRC) API to get the server version. I seem to remember Ludo's recent addition to FPC has this functionality. > Firebird has a long tradition of keeping the API and structures > backwards/forwards compatible, thus obliviating the need for different > units for each version. Yep. > Conclusion: At least for firebird, there will be 1 unit, loading > dynamically what is available. If you want to load something else than > the default, you have been able to do so since day 1. > > Contrary to Marco's belief, I am firmly convinced that this is the best > and easiest approach. As far as FB is concerned, that might indeed very well be true. Thanks, Reinier ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: Get all caller adresses of a given function/procedure before executing
Am Wednesday 15 August 2012 16:19:04 schrieb Marco van de Voort: > > > If your source (main) language has a word with two meanings, how will > > > you translate to a language where there is a word for each meaning? > > > > Then I can put an additional identifier like already mentioned. > > ls( '~ID1~word' ); > > ls( '~ID2~word' ); > > In this case ID1 or ID2 is the identifier instead of 'word'. > > > > But in all cases 'word' is the result of the translation of the original > > language. > > > > > IIRC dxgettext has only solutions for that when you recognize this > > > early and add special code. This means that sometimes you can't simply > > > ship a translation, but also have to > > > > In my case it can also be possible that there are not all words > > translated yet. Then the original text is shown or englich one. The > > translation can be made later. That is (also) an advantage. > > No it can't, since if two the same texts translate to a different texts in > another language, you need to add the identifiers and rebuild, > distribute/migrate etc. Look at the top. The programmer must be aware of the two meanings and add a unique identifyer in front of the text. What you want to discuss here is specific and (more or less) deep. You want from me immediately a solution to all this kind of specific things. > > ITE doesn't have this limitation, since the fully qualified identifier is > what uniquely identifies the text, not the content. See above. You can also add a unique identifier if you want. > The editor has some > features so that you don't have to translate something as "settings" twice. > > Moreover, ITE support widening and moving of components. (essentially > anything published in forms is editable without recompilation) > > > > (dx)gettext also has support for stuff like multiples, textdomains. > > > Some of it is not very well supported in the editor (gorm) though. > > > > I will use a browser as editor. So the utf8 (and unicode?) converting is > > made automatically by the browser. I have some code for converting ascii > > <-> utf8. > > What do you assume about the codepage of literals? Do you pass the right > -Fc parameters for that? Please explain it more. > > > It comes with source scanner tools to harvest strings from the code. > > > > Another step more that means more work and less easiness (less > > userfriendly). > > Explain. You need to scan some way too. Yes at programstart with searching the opcode for calls and loading the pchar const in EAX. Post from 11.08.2012 which is searching the caller adresses of a given function (parameter proc_adr). With another piece of code I can get the pointer of all pchars if this proc has one pchar parameter. It works! procedure i_really_know_what_i_am_doing( p_opcode : pbyte ; count : longint ; proc_adr : pointer ); const call_opcode = $e8; caller_adr_pc_offset = 5; var p_reladress : pdword; // call works with a relative adress after the opcode x , caller_adress , jmp_adr_abs : dword; begin for x := 1 to count do begin if p_opcode^ = call_opcode then begin p_reladress := pdword( p_opcode + 1 ); // after opcode = relative adress to procedure/function to call caller_adress := dword( p_opcode + caller_adr_pc_offset ); jmp_adr_abs := caller_adress + p_reladress^; // absolute adress = programcounter + 5 + relative adress if jmp_adr_abs = dword( proc_adr ) then add_caller_adress_to_table( caller_adress ); // if call proc_adr then found! end; inc( p_opcode ); end; end; > How do you handle combining translations btw? (e.g. general framework and > customer specific part on top of that?) Until now I did not come in contact with that. I don't know if it is necessary for me. So I don't need to spend the time now for that. But I am confident that there will be a solution for that. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Re: Get all caller adresses of a given function/procedure before executing
On 15/08/2012 15:17, Rainer Stratmann wrote: > > Then the > mov pcharconst , EAX > command also had changed. > At every start of the program I see if it works here. > If it works here ist works outside also. > >> For example if you add/remove units and rebuild. > > All pchar adresses are searched at programstart. > >> For example if FPC internals decide to add or remove some padding in front >> of the constants. > > Very unlikely. > For which reason should there be padding in front? For the reason that they always say not to rely on 'internal workings of the FPC' :) > I can not see any insolvable problem here. > Yeah. But it is labour intensive. >> Will all your translation work go to waste ? > > Then I would have a look at the opcodes directly and see what has been > changed > and likely find a solution. > See above. > If the maintainers decide to build in the suggested function above then > everthing is solved. By now no one of the maintainers wants this. > I can understand why, more or less - this could be a security flaw if you can find the final procedure call address like that [and then inject/patch it from outside, while the program is running - see what I mean?] Sort of the reason why Linux doesn't export System.map any more... And the sort of reason why (dx)gettext scans the _source_ not the binary. > I also can ask what happens if there are no more maintainers for fpc? Then you can fork it and maintain for you and for others for eternal glory :J Lukasz ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: linux: should we hard-code versioned or unversioned shared libraries in our apps?
Hi, On 15 August 2012 15:32, Reinier Olislagers wrote: > And you can use the (Firebird/Interbase Services IIRC) API to get the > server version. I seem to remember Ludo's recent addition to FPC has > this functionality. Yes, but you are jumping the gun here! My problem is that I can't even start my app, because the libfbclient.so is missing in every distro I tried. Linux distros (on client PC's at least), do not include the -devel packages by default, so they only have the versioned shared libraries setup. I had a quick look to see what other (non FPC based) application do. FlameRobin has a dependency on libfbclient.so.2 (thus versioned .so library). That's why it works without having to install the -devel package. So why does FCL-DB look at the unversioned *.so by default? Wouldn't it make more sense to change FCL-DB to look for libfbclient.so.2 instead? 2 being the latest major version of Firebird DB, and that is also the latest version that ibconnection.pp was written for. -- Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://fpgui.sourceforge.net ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: Get all caller adresses of a given function/procedure before executing
Am Wednesday 15 August 2012 16:45:03 schrieb Lukasz Sokol: > >> For example if FPC internals decide to add or remove some padding in > >> front of the constants. > > > > Very unlikely. > > For which reason should there be padding in front? > > For the reason that they always say not to rely on 'internal workings of > the FPC' :) For me it was quite easy to see a system in how the compiler generates the opcodes. There aren't this much variants to do so. > > I can not see any insolvable problem here. > > Yeah. But it is labour intensive. Initial search code about 3 hours work. Add another search method (which should be very rarely) about 10-30 minutes work I guess. > >> Will all your translation work go to waste ? > > > > Then I would have a look at the opcodes directly and see what has been > > changed and likely find a solution. > > See above. > > > If the maintainers decide to build in the suggested function above then > > everthing is solved. By now no one of the maintainers wants this. > > I can understand why, more or less - this could be a security flaw if you > can find the final procedure call address like that [and then inject/patch > it from outside, while the program is running - see what I mean?] Please explain. I do not change the code. I am only searching some pointers. > Sort of the reason why Linux doesn't export System.map any more... > And the sort of reason why (dx)gettext scans the _source_ not the binary. If the pointers were provided natively then scaning the source (labour intensive) is no more necessary. > > I also can ask what happens if there are no more maintainers for fpc? > > Then you can fork it and maintain for you and for others for eternal glory > :J Very huge labour intensive I think! ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: linux: should we hard-code versioned or unversioned shared libraries in our apps?
On Wed, 15 Aug 2012, Graeme Geldenhuys wrote: Hi, On 15 August 2012 15:32, Reinier Olislagers wrote: And you can use the (Firebird/Interbase Services IIRC) API to get the server version. I seem to remember Ludo's recent addition to FPC has this functionality. Yes, but you are jumping the gun here! My problem is that I can't even start my app, because the libfbclient.so is missing in every distro I tried. Linux distros (on client PC's at least), do not include the -devel packages by default, so they only have the versioned shared libraries setup. I had a quick look to see what other (non FPC based) application do. FlameRobin has a dependency on libfbclient.so.2 (thus versioned .so library). That's why it works without having to install the -devel package. So why does FCL-DB look at the unversioned *.so by default? Wouldn't it make more sense to change FCL-DB to look for libfbclient.so.2 instead? 2 being the latest major version of Firebird DB, and that is also the latest version that ibconnection.pp was written for. It makes sense. Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: linux: should we hard-code versioned or unversioned shared libraries in our apps?
On 15 Aug 2012, at 17:19, Michael Van Canneyt wrote: > On Wed, 15 Aug 2012, Graeme Geldenhuys wrote: > >> So why does FCL-DB look at the unversioned *.so by default? Wouldn't >> it make more sense to change FCL-DB to look for libfbclient.so.2 >> instead? 2 being the latest major version of Firebird DB, and that is >> also the latest version that ibconnection.pp was written for. > > It makes sense. FWIW, on Mac OS X Firebird only ships a libfbclient.dylib (no libfbclient.2.dylib -- on Mac OS X, the version number is placed before the shared library extension rather than after it). The reason is probably the library is not shipped with Mac OS X by default, so you have to embed the library/framework into your application bundle anyway and then you know which version you use). Jonas___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
RE : [fpc-pascal] Re: linux: should we hard-code versioned orunversioned shared libraries in our apps?
> So why does FCL-DB look at the unversioned *.so by default?
> Wouldn't it make more sense to change FCL-DB to look for
> libfbclient.so.2 instead? 2 being the latest major version of
> Firebird DB, and that is also the latest version that
> ibconnection.pp was written for.
>
Completely agreed.
The default library file can be overrided but this is all but self
explaining (and barely documented AFAIK):
- firebird: uses ibase60dyn; ... InitialiseIBase60('libraryname');
- postgres: uses postgres3dyn; ... InitialisePostgres3('libraryname');
- mysql5.1: uses mysql51dyn; ... InitialiseMysql('libraryname');
It can only be done at run-time, so no way to activate any connections in
the OI.
A libraryfilename property for the different sqldb components would be nice.
Ludo
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: RE : [fpc-pascal] Re: linux: should we hard-code versioned orunversioned shared libraries in our apps?
On Wed, 15 Aug 2012, Ludo Brands wrote:
So why does FCL-DB look at the unversioned *.so by default?
Wouldn't it make more sense to change FCL-DB to look for
libfbclient.so.2 instead? 2 being the latest major version of
Firebird DB, and that is also the latest version that
ibconnection.pp was written for.
Completely agreed.
The default library file can be overrided but this is all but self
explaining (and barely documented AFAIK):
- firebird: uses ibase60dyn; ... InitialiseIBase60('libraryname');
- postgres: uses postgres3dyn; ... InitialisePostgres3('libraryname');
- mysql5.1: uses mysql51dyn; ... InitialiseMysql('libraryname');
It can only be done at run-time, so no way to activate any connections in
the OI.
A libraryfilename property for the different sqldb components would be nice.
No, this would suggest that you can set a different value for each instance.
I think a settings dialog in the component editor (from the form designer)
would be better. Or a settings dialog under 'Tools'.
Patches welcome :-)
Michael.
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Don't understand Zipper.DoEndOfFile/UnZipper.DoEndOfFile
On 15-8-2012 14:24, Michael Van Canneyt wrote: > > > On Wed, 15 Aug 2012, Reinier Olislagers wrote: > >> On 15-8-2012 13:48, Michael Van Canneyt wrote: >>> On Wed, 15 Aug 2012, Reinier Olislagers wrote: >>> I've been working on documenting the Zipper/Unzipper classes: packages\paszlib\src\zipper.pp Now looking at the protected procedure TZipper/TUnzipper.DoEndOfFile They apparently update compression percentage statistics and call a user defined callback (if any, defined in OnEndOfFile) I don't understand though by whom/if they are called? A grep through the source code showed nothing referencing it. >>> >>> The calls to these routines must have fallen out during some >>> refactoring. They should be called when the zip/unzip operation is done. >> Ok, just for confirmation: done after each file in the list - as >> oppposed to the zip/unzip operation on the entire zip file, right? > > Yes. > >> I'll have a look through the history to see if I can find it and write >> up a patch. > > That would be nice :) Nice, separated hot, fresh patches ;) Patch for executing DoEndFile/hooking up OnEndOfFile: 22651 Basic test of zip/unzip functionality for compiler tests: 22648 Thanks, Reinier ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
RE : RE : [fpc-pascal] Re: linux: should we hard-code versionedorunversioned shared libraries in our apps?
> No, this would suggest that you can set a different value for > each instance. > I don't see what is wrong with that. You get a nice exception when you try to load a different library than the one that is alread loaded. But if I want to make an app that works with embedded firebird or firebird client (user selectable at any time) that have completely different settings (user, password, database, etc), what is I wrong with creating 2 instances in the OI and connect only one at the time? You can't be connected the 2 at the same time but that is a run-time issue, not design time. > I think a settings dialog in the component editor (from the > form designer) would be better. Or a settings dialog under 'Tools'. > Where would you store the value(s) then so that 1) it can be streamed 2) the instances can pick up the value (instances decide whether connection is active or not. Current implementation will load library when the first connection becomes active) 3) when using multiple db backends (FB + postgres for example) the instances pick up the correct library > Patches welcome :-) > ROFLMAO No comment. Ludo ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: RE : RE : [fpc-pascal] Re: linux: should we hard-code versionedorunversioned shared libraries in our apps?
On Wed, 15 Aug 2012, Ludo Brands wrote: No, this would suggest that you can set a different value for each instance. I don't see what is wrong with that. You get a nice exception when you try to load a different library than the one that is alread loaded. But if I want to make an app that works with embedded firebird or firebird client (user selectable at any time) that have completely different settings (user, password, database, etc), what is I wrong with creating 2 instances in the OI and connect only one at the time? IMHO that would be a total waste: Since you'll have to store username/password/db file anyway in some form of user settings, you might as well store the library name as well. It so happens that I have an application in production that does all this. It only requires a restart in case you choose another library. You can't be connected the 2 at the same time but that is a run-time issue, not design time. Because only 1 library can be loaded for each type of connection: the entry points are global. What you suggest implicates keeping a reference count, unloading, and then reloading. Ivo Steinmann tried implementing that once, and all his efforts were undone because it gave too much problems (specially the unloading if I recall correctly). I think a settings dialog in the component editor (from the form designer) would be better. Or a settings dialog under 'Tools'. Where would you store the value(s) then so that 1) it can be streamed It does not need to be streamed, I imagined an IDE setting only. You pointed out that one cannot set the library for the IDE; I merely point out a solution for that. The library name to use - per type of connection - can be stored in the IDE settings. 2) the instances can pick up the value (instances decide whether connection is active or not. Current implementation will load library when the first connection becomes active) But does not unload correctly. 3) when using multiple db backends (FB + postgres for example) the instances pick up the correct library The setting is for the IDE only: One setting per type of backend. I do not think a solution is required for the components. Yes, you cannot set the location in the OI, but I do not think this is needed in the first place, see the use case at the beginning. Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: RE : RE : [fpc-pascal] Re: linux: should we hard-code versionedorunversioned shared libraries in our apps?
On 15 August 2012 17:42, Ludo Brands wrote: > You can't be connected the 2 at the > same time but that is a run-time issue, not design time. I'm not sure I'm following. Do you mean SqlDB can't connect to two different database at the same time? I can't think that is true, so could you explain this limitation you are talking about. For example, in tiOPF I often connect to multiple databases - migrating data from one database to another. -- Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://fpgui.sourceforge.net ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: Get all caller adresses of a given function/procedure before executing
In our previous episode, Rainer Stratmann said:
> > > In my case it can also be possible that there are not all words
> > > translated yet. Then the original text is shown or englich one. The
> > > translation can be made later. That is (also) an advantage.
> >
> > No it can't, since if two the same texts translate to a different texts in
> > another language, you need to add the identifiers and rebuild,
> > distribute/migrate etc.
>
> Look at the top. The programmer must be aware of the two meanings and add a
> unique identifyer in front of the text. What you want to discuss here is
> specific and (more or less) deep. You want from me immediately a solution to
> all this kind of specific things.
No. The route was this:
- In an earlier msg I mentioned this as dxgettext limitation (since I ran
into it)
- In a later msg you said you got weary of dxgettext because of "problems"
with it.
- I replied that it was not a problem, but a limitation of the concept, and
that your system had it too.
I never asked you to have a solution for it. I don't see the particular
advantage of your system over gettext anyway.
> > > <-> utf8.
> >
> > What do you assume about the codepage of literals? Do you pass the right
> > -Fc parameters for that?
>
> Please explain it more.
If there is a _('whatever')(or whatever your notation is)
what do you assume about 'whatever' 's codepage?
> > > Another step more that means more work and less easiness (less
> > > userfriendly).
> >
> > Explain. You need to scan some way too.
>
> Yes at programstart with searching the opcode for calls and loading the pchar
> const in EAX.
_always_ ? Scary.
Anyway, my point was that you scan either which way. Source or binary.
The source has a build requirement, is architecture dependent and generally
more portable. Binary might be easier to only get the linkedin texts.
Actually proof of concept might be worthwhile for that purpose in combination
with gettext. OTOH, gettext alos translates stuff from resources (like
forms)
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: linux: should we hard-code versioned or unversioned shared libraries in our apps?
In our previous episode, Graeme Geldenhuys said:
> Hi,
>
> On 15 August 2012 15:32, Reinier Olislagers
> wrote:
> > And you can use the (Firebird/Interbase Services IIRC) API to get the
> > server version. I seem to remember Ludo's recent addition to FPC has
> > this functionality.
>
> Yes, but you are jumping the gun here! My problem is that I can't even
> start my app, because the libfbclient.so is missing in every distro I
> tried. Linux distros (on client PC's at least), do not include the
> -devel packages by default, so they only have the versioned shared
> libraries setup.
Did you try ibase60dyn.initializeibase60('whatever.so'); in your dpr ? I
noticed you didn't react to that suggestion (and a similar suggestion from
Jonas)
Since 2.4.2 afaik most db routines have such routines, though I haven't seen
them tested much.
The main reason is exactly discussions like this popping up every half year
about library naming purposes, adding embedded or odd ball versions and so on.
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
RE : RE : RE : [fpc-pascal] Re: linux: should we hard-codeversionedorunversioned shared libraries in our apps?
> -Message d'origine- > De : fpc-pascal-boun...@lists.freepascal.org > [mailto:fpc-pascal-boun...@lists.freepascal.org] De la part > de Michael Van Canneyt > > I don't see what is wrong with that. You get a nice > exception when you > > try to load a different library than the one that is alread loaded. > > But if I want to make an app that works with embedded firebird or > > firebird client (user selectable at any time) that have completely > > different settings (user, password, database, etc), what is I wrong > > with creating 2 instances in the OI and connect only one at > the time? > > IMHO that would be a total waste: > Since you'll have to store username/password/db file anyway in some > form of user settings, you might as well store the library > name as well. > Wasn't that what I suggested, a libraryfilename property for the connection component? Next to username/password/db. > > You can't be connected the 2 at the > > same time but that is a run-time issue, not design time. > > Because only 1 library can be loaded for each type of connection: > the entry points are global. > That is why I said it is a runtime issue, not a design time issue. > What you suggest implicates keeping a reference count, unloading, > and then reloading. > > Ivo Steinmann tried implementing that once, and all his efforts > were undone because it gave too much problems (specially the > unloading if I recall correctly). > What you are saying is that all the code in for example ibase60.inc, where ReleaseIBase60 calls UnloadLibrary when RefCount=0 is all unused? The debugger says the contrary. ReleaseIBase60 is called from TIBConnection.DoInternalDisconnect. > > > >> I think a settings dialog in the component editor (from the form > >> designer) would be better. Or a settings dialog under 'Tools'. > >> > > > > Where would you store the value(s) then so that > > 1) it can be streamed > > It does not need to be streamed, I imagined an IDE setting only. > Ah, that is not what I meant. Since Graeme's comments were mainly about rolling out applications on customer machines I didn't explicitly repeat that point. > You pointed out that one cannot set the library for the IDE; > I merely point out a solution for that. > Set the library -from- the IDE, ie. the Object Inspector. > The library name to use - per type of connection - can be > stored in the IDE settings. > I really don't see the use for such a setting on the IDE level. On the project level it could be useful. > I do not think a solution is required for the components. > Yes, you cannot set the location in the OI, but I do not think > this is needed in the first place, see the use case at the beginning. > We differ there. If it was easier to set the library file name we probably wouldn't have all these discussions on client not found or wrong client (embedded or not) loaded. Ludo. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: RE : RE : [fpc-pascal] Re: linux: should we hard-code versionedorunversioned shared libraries in our apps?
In our previous episode, Michael Van Canneyt said: > > I don't see what is wrong with that. You get a nice exception when you try > > to load a different library than the one that is alread loaded. But if I > > want to make an app that works with embedded firebird or firebird client > > (user selectable at any time) that have completely different settings (user, > > password, database, etc), what is I wrong with creating 2 instances in the > > OI and connect only one at the time? > > IMHO that would be a total waste: > Since you'll have to store username/password/db file anyway in some > form of user settings, you might as well store the library name as well. I might be wrong, but if Zeos behaviour is any comparison, I think this is all used designtime too? On a development system one can assume that the libfbclient symlink is there, and that is about the only certain point in this whole mess. Note that currently also multiple names are tested for some client libs. (e.g. fbembedded). That functionality should persist. And contrary to user apps with the most likely _current_ name, inserting a call on startup is much more annoying for Lazarus > Because only 1 library can be loaded for each type of connection: > the entry points are global. > > What you suggest implicates keeping a reference count, unloading, > and then reloading. > > Ivo Steinmann tried implementing that once, and all his efforts > were undone because it gave too much problems (specially the > unloading if I recall correctly). And IMHO this all reeks of that. (dll name in component). Sounds "easy", but it doesn't really solve anything. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
RE : RE : RE : [fpc-pascal] Re: linux: should we hard-codeversionedorunversioned shared libraries in our apps?
> > You can't be connected the 2 at the > > same time but that is a run-time issue, not design time. > > I'm not sure I'm following. Do you mean SqlDB can't connect > to two different database at the same time? I can't think > that is true, so could you explain this limitation you are > talking about. > 2 instances of the same database connections (ibconnection for example) using different librairies. For example having one connection that uses the FB embedded library and another that uses the FB client client library. That is not working. The connection library is global for all instances using the same ConnectionClass. Ludo ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: Get all caller adresses of a given function/procedure before executing
On 8/15/2012 03:33, Rainer Stratmann wrote: Am Wednesday 15 August 2012 03:52:00 schrieb waldo kitty: On 8/14/2012 03:11, Rainer Stratmann wrote: Am Tuesday 14 August 2012 03:28:26 schrieb waldo kitty: i've been following this whole thread with interest... one thing that i'm still not clear about, though, is why is this important? is it to see what areas of the program are actually used or something else? Yes. It has to do with that. ok... that's one part that is understandable from a statistics POV... I am not this experienced with the english language, so sorry if I do noz understand everything 100%. What means POV? sorry... acronym... Point Of View... ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: linux: should we hard-code versioned or unversioned shared libraries in our apps?
Am 15.08.2012 17:02 schrieb "Graeme Geldenhuys" : > I had a quick look to see what other (non FPC based) application do. > FlameRobin has a dependency on libfbclient.so.2 (thus versioned .so > library). That's why it works without having to install the -devel > package. Did you look at the source/makefile or the binary? If the latter then this is exactly what FPC (or more precisely the linker) does when you statically link to a shared library: the unversioned symlink is resolved and the versioned one is stored in the recuires section of the binary. Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: linux: should we hard-code versioned or unversioned shared libraries in our apps?
In our previous episode, Graeme Geldenhuys said: > I had a quick look to see what other (non FPC based) application do. > FlameRobin has a dependency on libfbclient.so.2 (thus versioned .so > library). That's why it works without having to install the -devel > package. Is that a cross-distro binary? Since that is exactly what you get when libraries wouldn't build with -dyn. Blend perfectly with the distro they are build for, but if changes occur chances on recovery are slim. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: linux: should we hard-code versioned or unversioned shared libraries in our apps?
Hi,
On 15 August 2012 19:02, Marco van de Voort wrote:
>
> Did you try ibase60dyn.initializeibase60('whatever.so'); in your dpr ?
I'm sure I can add that, and I'm sure it will work for my Firebird
connections, but other libraries I use don't have such functionality.
I'm trying to get to the bottom of
* Why must developers jump through hoops to get there DB apps to work
* Why did FPC decide to use unversioned shared libraries under linux when
they (fpc developers) clearly know than those -devel packages are
not installed
as standard - thus making deployment of FPC+DB apps unnecessary complex.
Yes it's great that the Firebird dynamic linking unit supports passing
in aditional library names, but why not simply use the correct name as
standard. Other apps that talk to Firebird link to libfbclient.so.2
because that is the latest version of Firebird, and when you install
the standard Firebird Client libraries, only the versioned ones are
installed.
I also believe that the ibconnection.pp unit is coded for Firebird 2.1
and 2.5, so assuming the default shared library (libfbclient.so.2) is
really not a great leap.
--
Regards,
- Graeme -
___
fpGUI - a cross-platform Free Pascal GUI toolkit
http://fpgui.sourceforge.net
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: linux: should we hard-code versioned or unversioned shared libraries in our apps?
On 15 August 2012 21:53, Sven Barth wrote: > Did you look at the source/makefile or the binary? If the latter then this > is exactly what FPC (or more precisely the linker) does when you statically > link to a shared library Yes, FlameRobin was statically linked. But that's beside the point. It works in FPC is you statically like your SqlDB+Firebird application (though I had a libfbclient.so symlink already), but it fails if you dynamically link that same app. Not to mention that SqlDB defaults to dynamically linked - something myself and others seem to prefer. I just think ibconnection.pp should rather look at the versioned shared library, just like the linker does with static linking. Thus making applications easier to deploy. Is that too much to ask? -- Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://fpgui.sourceforge.net ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: linux: should we hard-code versioned or unversioned shared libraries in our apps?
On 15 August 2012 22:10, Marco van de Voort wrote: > Blend perfectly with the distro they are build for, but if changes occur > chances on recovery are slim. Be more specific, what changes? Dynamic linking and Static linking both have there pros and cons. Most seem to prefer dynamic linking, that is why it is the default in ibconnection.pp. Only problem at the moment in FPC is, with dynamic linking it is looking for an unversioned library instead of libfbclient.so.2 (the latest major version of Firebird DB). Making that simple change means apps that are dynamically linked can be just as easily deployed as apps with static linking. -- Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://fpgui.sourceforge.net ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: linux: should we hard-code versioned or unversioned shared libraries in our apps?
In our previous episode, Graeme Geldenhuys said: > I'm sure I can add that, and I'm sure it will work for my Firebird > connections, but other libraries I use don't have such functionality. > > I'm trying to get to the bottom of > * Why must developers jump through hoops to get there DB apps to work It's not a FPC problem, it is a linux problem that apps are not crossdistribution distributable. Creating a lot of drama if you see a minor discrepancy here 6 months after release won't benefit anyone. Just like we had a similar drama discussions about adding fbembedded 9 months ago, we'll just rehash this charade in 9 months for some other library where a new version came out or where naming changed. > * Why did FPC decide to use unversioned shared libraries under linux when > they (fpc developers) clearly know than those -devel packages are > not installed > as standard - thus making deployment of FPC+DB apps unnecessary complex. > Because it is the _only_ fixed point in this whole mess. This sounds all very smart now, but once .2 will start changing you can explain people how to fix everything so that designtime components keep working. (and installing -dev won't help, manual intervention must be done) > Yes it's great that the Firebird dynamic linking unit supports passing > in aditional library names, but why not simply use the correct name as > standard. > Other apps that talk to Firebird link to libfbclient.so.2 Which apps, do they dlload at all? ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: linux: should we hard-code versioned or unversioned shared libraries in our apps?
In our previous episode, Graeme Geldenhuys said: > > Blend perfectly with the distro they are build for, but if changes occur > > chances on recovery are slim. > > Be more specific, what changes? Change in naming, (either root (gds->fbclient) or version numbers) non standard directories (the $prefix/lib/mysql/ has been a problem in the past). 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. With a low FPC release frequency and distro packages that generally not fix this on their own, this is a lost battle. And despite all assurances that this change is all pretty invariant, this discussion returns in some way or the other every 6-9 months as new developments occur. (or, like in thise case, if somebody wants to be smart and turns the screws on status quo a bit tighter). If dynamic linking is so great, why do we constant, constantly have these discussions and worse all these illadvised changes? IMHO dynamic linking is a boon for a few people that want attempt crossdistro distribution, and a burden on everything else. > Dynamic linking and Static linking both have there pros and cons. Most > seem to prefer dynamic linking, that is why it is the default in > ibconnection.pp. An "it is because it is" argument. Fact is that we don't support the distribution recommended way. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Re: linux: should we hard-code versioned or unversioned shared libraries in our apps?
On 16-8-2012 5:31, Marco van de Voort wrote: > It's not a FPC problem, it is a linux problem that apps are not > crossdistribution distributable. Creating a lot of drama if you see a > minor discrepancy here 6 months after release won't benefit anyone. > > Just like we had a similar drama discussions about adding fbembedded 9 > months ago, we'll just rehash this charade in 9 months for some other > library where a new version came out or where naming changed. Don't know what drama you refer to exactly (quick search through the archives on fbembed showed nothing relevant) but for the Windows side: fbembed.dll is a DLL distributed by the Firebird installer, just like fbclient.dll (and, if you go the masochistic route, if you check the box on installation, perhaps gds32.dll will also be installed). I don't see how sqldb not searching for fbembed.dll by default and letting devs search for this manually in their program for every program makes things easier. As for Linux: if libfbembed is distributed by the distro packages... well, yes, it might be a "drama" to add it to ibase60.inc, but doing things half way and leaving only libgds and libfbclient there will only confuse things more. Is a change every say 9 months really such a big problem? Why not add an FPC FAQ entry (if it's not already there) stating these problems and decisions, and say that mainstream library names will be added after name changes, but indicate the delay you mentioned. Either something like that or throw out the entire concept and force devs to specify library names in every program... ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
