On Tue, Aug 16, 2016 at 10:11:15AM +0200, Rene Engelhard wrote:
> On Tue, Aug 16, 2016 at 09:49:20AM +0200, Lionel Elie Mamane wrote:
>> I think we would be opening another can of worms:
>> * version management and data format compatibility
> You already need to care about this. There's distrib
Hi,
On Tue, Aug 16, 2016 at 09:49:20AM +0200, Lionel Elie Mamane wrote:
> I think we would be opening another can of worms:
>
> * version management and data format compatibility
You already need to care about this. There's distributions which WILL (and
did, although one can argue the firebird
On Mon, Aug 15, 2016 at 08:57:04AM +0200, Noel Grandin wrote:
> Just a random thought - it seems like linking firebird into LO is a
> lot of pain.
> Is there any real downside to just building firebird as an
> executable and then running it as a sub-process of LO?
We still need to link to the cl
On 15 August 2016 at 08:57, Noel Grandin wrote:
>
> Just a random thought - it seems like linking firebird into LO is a lot of
> pain.
>
> Is there any real downside to just building firebird as an executable and
> then running it as a sub-process of LO?
The difficulty I run into is actually that
Just a random thought - it seems like linking firebird into LO is a lot of pain.
Is there any real downside to just building firebird as an executable and then
running it as a sub-process of LO?
It just seems to me that we're running "against the grain" here - firebird is a large complex appli
>> It seems, I can use dylib tokens like
>> "@loader_path/libEngine12.dylib" in the string passed to dlopen.
>
> I don't know. I don't find a reference online that says that dlopen
> understands those tokens. Did you find some documentation that says it
> does? I see it only referenced about depend
On Fri, Aug 12, 2016 at 11:09:38PM +0200, Bunth Tamás wrote:
>> On MacOS X, when A is dynamically linked with B (that is at build
>> time), the "install path" of B is recorded into A (more precisely,
>> into the result of linking A with B), so that at runtime (link
>> before the executable is run,
> On MacOS X, when A is dynamically linked with B (that is at build
> time), the "install path" of B is recorded into A (more precisely,
> into the result of linking A with B), so that at runtime (link before
> the executable is run, not dlopen()), B is searched for B's "install
> path".
>
> So the
Hi,
On MacOS X, "install path" is kindof the reverse of "rpath".
On GNU/Linux, when A loads B with dlopen() (that is at runtime), then
the rpath of A is used to search for B.
On MacOS X, when A is dynamically linked with B (that is at build
time), the "install path" of B is recorded into A (more
>> I believe Firebird3 now supports auto-increment columsn
>>
>> http://stackoverflow.com/questions/34553826/easiest-way-to-create-an-auto-increment-field-in-firebird-database
>
> I see that your latest gerrit revision takes that in account. Good! I
> should have some time this week-end to do a
On Wed, Jun 29, 2016 at 10:16:01AM +0200, Noel Grandin wrote:
> On 2016/06/28 8:18 PM, Bunth Tamás wrote:
>> Currently I'm working on implementing auto increment columns for the
>> Firebird sdbc driver.
> I believe Firebird3 now supports auto-increment columsn
>
> http://stackoverflow.com/quest
On 2016/06/28 8:18 PM, Bunth Tamás wrote:
Currently I'm working on implementing auto increment columns for the
Firebird sdbc driver.
I believe Firebird3 now supports auto-increment columsn
http://stackoverflow.com/questions/34553826/easiest-way-to-create-an-auto-increment-field-in-firebird
> On 19 Jun 2016, at 20:28, Bunth Tamás wrote:
>
> Now I think both my patches work:
> https://gerrit.libreoffice.org/25673/
> https://gerrit.libreoffice.org/26188/
>
> Except that the Update to Firebird 3.0 part is working only on GNU/Linux.
>
> Should I submit them to gerrit as a patch read
13 matches
Mail list logo
