On Thu, 5 Jan 2023, Wayne Sherman via fpc-devel wrote:
The google api binding generator "googleapiconv" is generating empty
files for the api pascal bindings and it also causes access violations
randomly. I have not found the issue with AVs yet, but I found out
why it is creating empty
The google api binding generator "googleapiconv" is generating empty
files for the api pascal bindings and it also causes access violations
randomly. I have not found the issue with AVs yet, but I found out
why it is creating empty source code files.
restcodegen.pp TRestCodeGenerator was
On 11.11.2015 17:47, Michael Van Canneyt wrote:
I have several remarks:
a) Your TBaseSingleInstance class contains too many methods.
It assumes you are using advancedipc.
I refactored TBaseSingleInstance so that it doesn't depend on advancedipc.
I suggest refactoring such a way that
On 29.09.2015 12:52, Michael Van Canneyt wrote:
Juha, if you want to implement the single IDE instance, then I would
like to ask you to implement this in custapp.pp. This is useful
functionality for all kinds of applications, and is since very long on
my todo list.
On 30.09.2015 18:50,
On Wed, 11 Nov 2015, Ondrej Pokorny wrote:
On 29.09.2015 12:52, Michael Van Canneyt wrote:
Juha, if you want to implement the single IDE instance, then I would like
to ask you to implement this in custapp.pp. This is useful functionality
for all kinds of applications, and is since very long
On 11.11.2015 17:47, Michael Van Canneyt wrote:
I checked the patch and applied it, so people can try it.
I have several remarks:
a) Your TBaseSingleInstance class contains too many methods.
It assumes you are using advancedipc.
I suggest refactoring such a way that advancedipc is in the
On 03.10.2015 19:21, Tomas Hajny wrote:
Thanks, I tested it under OS/2 now. Both the "simple" and "advanced"
test programs work, well done! I noticed two issues when running the
"advanced" tests, though. First, the server increases the CPU
considerably. There seems to be a loop permanently
On 03.10.2015 19:21, Tomas Hajny wrote:
Thanks, I tested it under OS/2 now. Both the "simple" and "advanced"
test programs work, well done! I noticed two issues when running the
"advanced" tests, though. First, the server increases the CPU
considerably. There seems to be a loop permanently
On 03.10.2015 19:21, Tomas Hajny wrote:
Thanks, I tested it under OS/2 now. Both the "simple" and "advanced"
test programs work, well done! I noticed two issues when running the
"advanced" tests, though. First, the server increases the CPU
considerably. There seems to be a loop permanently
On 21 Sep 15, at 14:03, Ondrej Pokorny wrote:
.
.
> Michael Van Canneyt & Tomas Hajny & everybody who wants to test:
>
> I prepared a fully compatible AdvancedIPC unit. See the attachment.
> There is a unit mysimpleipc.pp that should replace the simpleipc.pp in
> FPC sources. I renamed it in
On Sat, October 3, 2015 19:59, Ondrej Pokorny wrote:
> On 03.10.2015 19:21, Tomas Hajny wrote:
>> Thanks, I tested it under OS/2 now. Both the "simple" and "advanced"
>> test programs work, well done! I noticed two issues when running the
>> "advanced" tests, though. First, the server increases
On Sat, October 3, 2015 19:54, Ondrej Pokorny wrote:
> On 03.10.2015 19:21, Tomas Hajny wrote:
.
.
> Attached patched for FPC and Lazarus to sync advancedipc.pp. The current
> version in FPC trunk is out-dated (the Lazarus trunk version just misses
> the AllFilesMask constant).
Thanks, I
On 29.09.2015 22:47, Michael Van Canneyt wrote:
Let's first see how Ondrej does it.
See the patch attached. A simple demo program is attached as well
(SITest.lpr).
advancedipc.pp: refactoring MsgID -> RequestID and some smaller issues
solved. API hasn't changed.
singleinstance.pp: class
On Tue, Sep 29, 2015 at 2:50 PM, Michael Van Canneyt
wrote:
> I am not proposing to make a new class.
> I want a property "SingeInstance" in CustApp which activates this
> automatically.
I had the very same idea when this was discussed a long time ago in
Lazarus list.
On 29.09.2015 14:42, Michael Van Canneyt wrote:
On Tue, 29 Sep 2015, Ondrej Pokorny wrote:
OK, I see your point. Yes, I think it is possible and even not that
much work to do.
I programmed "multiple instances" handling into Lazarus IDE. It's the
same like e.g. Adobe Photoshop or VLC player
On Tue, 29 Sep 2015, Ondrej Pokorny wrote:
On 29.09.2015 12:52, Michael Van Canneyt wrote:
I added it to fpc/packages/fcl-base. It compiles OK, there are no dangerous
dependencies except sysutils and classes.
Michael, you added the wrong (old) unit from the bug report, not the latest
On 29.09.2015 12:52, Michael Van Canneyt wrote:
I added it to fpc/packages/fcl-base. It compiles OK, there are no
dangerous dependencies except sysutils and classes.
Michael, you added the wrong (old) unit from the bug report, not the
latest simpleipc-compatible one from the mailing list.
On 29.09.2015 15:42, Ondrej Pokorny wrote:
On 29.09.2015 12:52, Michael Van Canneyt wrote:
I added it to fpc/packages/fcl-base. It compiles OK, there are no
dangerous dependencies except sysutils and classes.
Michael, you added the wrong (old) unit from the bug report, not the
latest
On Tue, Sep 29, 2015 at 2:35 PM, Ondrej Pokorny wrote:
> Juha, I changed the advancedipc.pas unit (this one from the mailing list is
> newer than from the bug report). I can prepare a new patch for the bug
> report.
No need for a new patch if it did not change otherwise. I
On 29.09.2015 15:01, Juha Manninen wrote:
On Tue, Sep 29, 2015 at 2:35 PM, Ondrej Pokorny wrote:
Juha, I changed the advancedipc.pas unit (this one from the mailing list is
newer than from the bug report). I can prepare a new patch for the bug
report.
No need for a new
On Tue, 29 Sep 2015, Juha Manninen wrote:
On Tue, Sep 29, 2015 at 2:50 PM, Michael Van Canneyt
wrote:
I am not proposing to make a new class.
I want a property "SingeInstance" in CustApp which activates this
automatically.
I had the very same idea when this was
On Tue, Sep 29, 2015 at 4:35 PM, Michael Van Canneyt
wrote:
> For simpleIPC, yes. But the new implementation has no dependencies except
> sysutils, classes. So the argument becomes void.
It adds extra code to every application. Maybe not too much though.
> ...
> That is
On Tue, 29 Sep 2015, Ondrej Pokorny wrote:
On 29.09.2015 15:35, Michael Van Canneyt wrote:
1. Using a LCL component means that you must instantiate a form/datamodule
first.
By that time, a database connection may already have been made (just
to name something), which is exactly what
On 29.09.2015 15:35, Michael Van Canneyt wrote:
1. Using a LCL component means that you must instantiate a
form/datamodule first.
By that time, a database connection may already have been made (just
to name something), which is exactly what you want to avoid.
The check for single
On Tue, 29 Sep 2015, Ondrej Pokorny wrote:
On 29.09.2015 13:50, Michael Van Canneyt wrote:
You may not think this is important, but for beginners, this can be a
tremendous aid.
The easier we make it, the better. Lazarus is a RAD environment, after all.
Michael.
OK, I see your point.
On 29.09.2015 12:52, Michael Van Canneyt wrote:
I added it to fpc/packages/fcl-base. It compiles OK, there are no
dangerous dependencies except sysutils and classes.
Michael, you added the wrong (old) unit from the bug report, not the
latest simpleipc-compatible one from the mailing list.
On Mon, Sep 21, 2015 at 3:03 PM, Ondrej Pokorny wrote:
> Michael Van Canneyt & Tomas Hajny & everybody who wants to test:
>
> I prepared a fully compatible AdvancedIPC unit. See the attachment.
> ...
Michael and Tomas, I am planning to copy AdvancedIPC temporarily to
Lazarus
On 29.09.2015 13:50, Michael Van Canneyt wrote:
You may not think this is important, but for beginners, this can be a
tremendous aid.
The easier we make it, the better. Lazarus is a RAD environment, after
all.
Michael.
OK, I see your point. Yes, I think it is possible and even not that
On Tue, 29 Sep 2015, Ondrej Pokorny wrote:
On 29.09.2015 12:52, Michael Van Canneyt wrote:
I added it to fpc/packages/fcl-base. It compiles OK, there are no dangerous
dependencies except sysutils and classes.
Thanks!
Juha, if you want to implement the single IDE instance, then I would
On Tue, September 29, 2015 12:30, Juha Manninen wrote:
> On Mon, Sep 21, 2015 at 3:03 PM, Ondrej Pokorny wrote:
>> Michael Van Canneyt & Tomas Hajny & everybody who wants to test:
>>
>> I prepared a fully compatible AdvancedIPC unit. See the attachment.
>> ...
>
> Michael and
On 29.09.2015 12:52, Michael Van Canneyt wrote:
I added it to fpc/packages/fcl-base. It compiles OK, there are no
dangerous dependencies except sysutils and classes.
Thanks!
Juha, if you want to implement the single IDE instance, then I would
like to ask you to implement this in
On Tue, 29 Sep 2015, Tomas Hajny wrote:
On Tue, September 29, 2015 12:30, Juha Manninen wrote:
On Mon, Sep 21, 2015 at 3:03 PM, Ondrej Pokorny wrote:
Michael Van Canneyt & Tomas Hajny & everybody who wants to test:
I prepared a fully compatible AdvancedIPC unit. See the
On Tue, 29 Sep 2015, Luiz Americo Pereira Camara wrote:
2015-09-29 11:50 GMT-03:00 Luiz Americo Pereira Camara <
luizameri...@gmail.com>:
It can be used without the component. The component is just a convenience.
See the examples
2015-09-29 10:35 GMT-03:00 Michael Van Canneyt :
>
>
> On Tue, 29 Sep 2015, Juha Manninen wrote:
>
> On Tue, Sep 29, 2015 at 2:50 PM, Michael Van Canneyt
>> wrote:
>>
>>> I am not proposing to make a new class.
>>> I want a property "SingeInstance"
On Tue, 29 Sep 2015, Luiz Americo Pereira Camara wrote:
2. Then it is only available in visually designed applications.
Services, website servers and custom console apps are non-visual.
I am specificially thinking FastCGI processes.
See above
I didn't say it could not be done with
2015-09-29 11:50 GMT-03:00 Luiz Americo Pereira Camara <
luizameri...@gmail.com>:
>
>
> It can be used without the component. The component is just a convenience.
> See the examples
>
https://github.com/blikblum/luipack/blob/master/uniqueinstance/testraw/project1.lpr
Luiz
Unit uniqueinstanceraw
Please look carefully
Luiz
Em 29/09/2015 12:01, "Michael Van Canneyt"
escreveu:
>
>
> On Tue, 29 Sep 2015, Luiz Americo Pereira Camara wrote:
>
> 2015-09-29 11:50 GMT-03:00 Luiz Americo Pereira Camara <
>> luizameri...@gmail.com>:
>>
>>
>>>
>>> It
On 29.09.2015 16:09, Michael Van Canneyt wrote:
Both are OK. Use of one does not exclude use of the other.
I was going to add it in CustApp anyway as soon as I had looked at
your implementation.
I started working on the CustApp variant. It's even simpler than the LCL
component because you
On Tue, 29 Sep 2015, Luiz Americo Pereira Camara wrote:
On the other side, i still think that should be kept out of TCustomApplication.
Well, I have already explained why I want it exactly there :)
While the simple requirement of checking another
instance is easy to implement into
On Tue, 29 Sep 2015, Ondrej Pokorny wrote:
On 29.09.2015 16:09, Michael Van Canneyt wrote:
Both are OK. Use of one does not exclude use of the other.
I was going to add it in CustApp anyway as soon as I had looked at your
implementation.
I started working on the CustApp variant. It's
On Tue, 29 Sep 2015, Luiz Americo Pereira Camara wrote:
Unit uniqueinstanceraw
Please look carefully
My sincere apologies,
I was too fast and indeed opened the wrong unit. uniqueinstance, and
uniqueinstancebase, not uniqueinstanceraw :(
So, it could be used as well, if we can sort
2015-09-29 16:12 GMT-03:00 Michael Van Canneyt :
>
>
> On Tue, 29 Sep 2015, Luiz Americo Pereira Camara wrote:
>
> Unit uniqueinstanceraw
>>
>
>
>> Please look carefully
>>
>
> My sincere apologies,
>
>
No problem.
To be clear, i don't plead to uniqueinstance be used by
On 09/15/2015 12:07 PM, Tomas Hajny wrote:
On Tue, September 15, 2015 10:04, Michael Van Canneyt wrote:
On Tue, 15 Sep 2015, Ondrej Pokorny wrote:
.
.
Are there some high level crossplatform semaphore functions in the FCL?
The cthreads/cIntSemaphoreOpen etc. seem to be available on unix
I've developed a "single/multiple instances" feature for the Lazarus
IDE. For this feature I need an IPC. First I tried to use simpleipc but
I have struggled on bugs and missing functionality.
Particularly what I found:
1.) BUG: You can register multiple servers on Windows with the same name
On Tue, September 15, 2015 08:58, Michael Van Canneyt wrote:
> On Mon, 14 Sep 2015, Ondrej Pokorny wrote:
>
>> I've developed a "single/multiple instances" feature for the Lazarus
>> IDE. For
>> this feature I need an IPC. First I tried to use simpleipc but I have
>> struggled on bugs and missing
On Mon, 14 Sep 2015, Ondrej Pokorny wrote:
I've developed a "single/multiple instances" feature for the Lazarus IDE. For
this feature I need an IPC. First I tried to use simpleipc but I have
struggled on bugs and missing functionality.
Particularly what I found:
1.) BUG: You can register
On 15.09.2015 08:58, Michael Van Canneyt wrote:
On Mon, 14 Sep 2015, Ondrej Pokorny wrote:
I've developed a "single/multiple instances" feature for the Lazarus
IDE. For this feature I need an IPC. First I tried to use simpleipc
but I have struggled on bugs and missing functionality.
On Tue, 15 Sep 2015, Ondrej Pokorny wrote:
On 15.09.2015 08:58, Michael Van Canneyt wrote:
On Mon, 14 Sep 2015, Ondrej Pokorny wrote:
I've developed a "single/multiple instances" feature for the Lazarus IDE.
For this feature I need an IPC. First I tried to use simpleipc but I have
On 15/09/15 13:33, Ondrej Pokorny wrote:
This is because Michael Van Canneyt pointed me to "man sem_overview".
The first Google search pointed me to
http://linux.die.net/man/7/sem_overview where I found the "Named
semaphores" with functions sem_open, sem_close etc. with the
description that
On 15.09.2015 13:22, Michael Schnell wrote:
On 09/15/2015 01:09 PM, Michael Van Canneyt wrote:
IPC = Inter PROCESS Communication.
I know that you know this, but Ondrej is talking about cthreads in one
of his message, so I tried to politely set a trigger.
-Michael
This is because Michael
On Tue, 15 Sep 2015, Michael Schnell wrote:
On 09/14/2015 03:56 PM, Ondrej Pokorny wrote:
3.) MISSING: Multiple clients (from different processes) talk to one
server.
4.) MISSING: Client is able to receive a response on a request.
5.) MISSING: (Optionally, not default) client sends a
On 09/15/2015 01:09 PM, Michael Van Canneyt wrote:
IPC = Inter PROCESS Communication.
I know that you know this, but Ondrej is talking about cthreads in one
of his message, so I tried to politely set a trigger.
-Michael
___
fpc-devel maillist -
On Tue, September 15, 2015 10:04, Michael Van Canneyt wrote:
> On Tue, 15 Sep 2015, Ondrej Pokorny wrote:
.
.
>> Are there some high level crossplatform semaphore functions in the FCL?
>> The
>> cthreads/cIntSemaphoreOpen etc. seem to be available on unix only. What
>> about
>> OS/2?
>
>
On Tue, 15 Sep 2015, Tomas Hajny wrote:
On Tue, September 15, 2015 10:04, Michael Van Canneyt wrote:
On Tue, 15 Sep 2015, Ondrej Pokorny wrote:
.
.
Are there some high level crossplatform semaphore functions in the FCL?
The
cthreads/cIntSemaphoreOpen etc. seem to be available on unix only.
On 09/14/2015 03:56 PM, Ondrej Pokorny wrote:
3.) MISSING: Multiple clients (from different processes) talk to one
server.
4.) MISSING: Client is able to receive a response on a request.
5.) MISSING: (Optionally, not default) client sends a request to a
server that isn't running. The server is
On 09/15/2015 02:43 PM, Michael Van Canneyt wrote:
With my paranoid mind I of course assumed you were hijacking the
thread...
Of course I was eagerly waiting on Ondrej to confirm that he was looking
for thread support :-) :-) :-)
-Michael
___
On Tue, 15 Sep 2015, Michael Schnell wrote:
On 09/15/2015 01:09 PM, Michael Van Canneyt wrote:
IPC = Inter PROCESS Communication.
I know that you know this, but Ondrej is talking about cthreads in one of his
message, so I tried to politely set a trigger.
With my paranoid mind I of
On 8-4-2013 14:49, peter green wrote:
Michel Catudal wrote:
I am also having some issues with Lazarus, I am not sure if it is the
right forum to talk about it. I had a previous version working fine
on Rasphberry Pi.
For some reason I can't get it to work on Mele A2000G. I have
compiled it on
Michel Catudal wrote:
I am also having some issues with Lazarus, I am not sure if it is the
right forum to talk about it. I had a previous version working fine on
Rasphberry Pi.
For some reason I can't get it to work on Mele A2000G. I have compiled
it on gentoo on the Mele, using distcc and
- Original Message -
From: peter green plugw...@p10link.net
To: FPC developers' list fpc-devel@lists.freepascal.org
Sent: Monday, April 8, 2013 8:49:06 AM
Subject: Re: [fpc-devel] Lazarus issues on ARM Linux
Michel Catudal wrote:
I am also having some issues with Lazarus, I am
Le 2013-04-08 13:44, mcatu...@comcast.net a écrit :
I am not using an upstream binary file but compiled my own on gentoo. On
gentoo you compile everything. The scripts that come with gentoo ARM are
setup for hard floats only. I will check what you are saying tonight anyway.
I will first
I am also having some issues with Lazarus, I am not sure if it is the right
forum to talk about it. I had a previous version working fine on Rasphberry Pi.
For some reason I can't get it to work on Mele A2000G. I have compiled it on gentoo on the Mele, using distcc and locally, same results. I
Am 08.04.2013 02:34 schrieb Michel Catudal mcatu...@comcast.net:
I am also having some issues with Lazarus, I am not sure if it is the
right forum to talk about it. I had a previous version working fine on
Rasphberry Pi.
For some reason I can't get it to work on Mele A2000G. I have compiled it
Hello,
Two questions I wanted to ask:
1) There are two variant type defintions (varxxx constants): one in compiler/symdef.pas, another one
in rtl/inc/varianth.inc. Worse, they are out of sync. Is it really necessary to have a separate set
of these definitions in compiler?
2) In FPC,
Am 11.11.2010 15:19, schrieb Sergei Gorelkin:
Hello,
Two questions I wanted to ask:
1) There are two variant type defintions (varxxx constants): one in
compiler/symdef.pas, another one in rtl/inc/varianth.inc. Worse, they
are out of sync. Is it really necessary to have a separate set of
Florian Klaempfl пишет:
Am 11.11.2010 15:19, schrieb Sergei Gorelkin:
Hello,
Two questions I wanted to ask:
1) There are two variant type defintions (varxxx constants): one in
compiler/symdef.pas, another one in rtl/inc/varianth.inc. Worse, they
are out of sync. Is it really necessary to have
Looking at the code below...
{$if defined(ver2_0)}
{$note This is not delphi compatible. }
{$endif}
Is this a feature or a FPC bug? FPC allows the $IF to be closed with
the $ENDIF as well as the $IFEND. This is not Delphi compatible.
The closing tag for $IF is $IFEND
The closing
Op Mon, 14 Aug 2006, schreef Graeme Geldenhuys:
On 8/14/06, Peter Vreman [EMAIL PROTECTED] wrote:
Is this a feature or a FPC bug? FPC allows the $IF to be closed
with
the $ENDIF as well as the $IFEND. This is not Delphi compatible.
The closing tag for $IF is $IFEND
The
On 8/14/06, Vincent Snijders [EMAIL PROTECTED] wrote:
You miss the point: Delphi compatibility mode is for people who develop for
FPC, but
want to compile occasionally in Delphi. In the current situation they are not
aware
of this weakness of Delphi (no support of $ENDIF for $IF), until they
Op Mon, 14 Aug 2006, schreef Vincent Snijders:
You miss the point: Delphi compatibility mode is for people who develop for
FPC, but want to compile occasionally in Delphi.
It can be used that way, but its main purpose is to support Delphi
constructions that we consider broken and therefore
On Mon, 14 Aug 2006, Daniël Mantione wrote:
Op Mon, 14 Aug 2006, schreef Vincent Snijders:
You miss the point: Delphi compatibility mode is for people who develop for
FPC, but want to compile occasionally in Delphi.
It can be used that way, but its main purpose is to support Delphi
On 8/14/06, Daniël Mantione [EMAIL PROTECTED] wrote:
mode. To write new code that is compilable by both FPC and Delphi, Objpas
mode should suit as well as Delphi mode.
Not quite! The project I am working on (tiOPF) is mainly used by
Delphi developers, as I mentioned before. My first thought
Graeme Geldenhuys wrote:
On 8/14/06, Vincent Snijders [EMAIL PROTECTED] wrote:
You miss the point: Delphi compatibility mode is for people who
develop for FPC, but
want to compile occasionally in Delphi. In the current situation they
are not aware
of this weakness of Delphi (no support of
Op Tue, 18 Jul 2006, schreef Jonas Maebe:
You need something more than merely the remapping of library names.
As I said, you can remap unit names. At some point the user will have to
decide to which one he wants to link, doing it by a unit name remap looks
an elegant solution to me.
I
On Monday 17 July 2006 15:33, Micha Nelissen wrote:
Vinzent Hoefler wrote:
Of course they don't. Unlike some other languages where such things
are standardized quite clearly, (most) consistency, dependency and
linking issues are beyond the scope of the official C-standard.
I'm not talking
Tue, Jul 18, 2006 at 01:22:40AM +0200, Jonas Maebe wrote:
libnames when determining how to link, with the default being 1:1.
I know, but I was trying to point out that e.g. on Mac OS X sometimes
you may need
-lgtk-1.2.0 -lgdk-1.2.0 -lgdk_pixbuf
and sometimes
-framework Gtk+-Cocoa
Alright everyone, just stop this ok?
I was angry like hell when I first read the ORIGINAL poster's message
about FreeBSD (hint, topic no longer valid in your discussion) I got
even more angry and my response was very immature. I would like to
apologise to everyone and especialy the original
On 18 Jul 2006, at 12:05, Aleš Katona wrote:
This whole discussion is useless.
Better library linking support is not useless.
Jonas___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Ale? Katona wrote:
Btw. fpc 2.0.2 is in ports now.
Just a binary distribution right? I did not see the sources in ports,
which would have to be patched to fix the lib naming errors.
You need to symlink those libraries or patch manualy, but we
Just a binary distribution right? I did not see the sources in ports,
which would have to be patched to fix the lib naming errors.
Yes but one guy said he's working on source based one.
Are you saying that code produced by this Lazarus/FPC setup will not run
properly on older freebsd
Greetings to the Fpc-Devel list:
the following libraries were not found by ld: glib12, gdk12, and gtk12.
This is a know issue without good solution, since the problem originates in
the FreeBSD ports management.
The best solution is:
- for 2.0.2 manually create relevant symlinks to the
Aleš Katona wrote:
Hi Bob and welcome to the world of crap.
Seriously and honestly, the FreeBSD porters made a big bad pile of crap
when they some years ago decided to name gtk-12 and others as gtk12.
Welcome to the world of shit.. eh sorry I ment unix.
It was written in C what would
Ale? Katona wrote:
Hi Bob and welcome to the world of crap.
Seriously and honestly, the FreeBSD porters made a big bad pile of crap
when they some years ago decided to name gtk-12 and others as gtk12.
Welcome to the world of shit.. eh sorry I ment unix.
It was written in C what
On Mon, 17 Jul 2006, Marco van de Voort wrote:
Greetings to the Fpc-Devel list:
the following libraries were not found by ld: glib12, gdk12, and gtk12.
This is a know issue without good solution, since the problem originates in
the FreeBSD ports management.
The best solution is:
- for
On Mon, Jul 17, 2006 at 10:50:33AM +0200, Michael Van Canneyt wrote:
- for 2.0.2 manually create relevant symlinks to the libs.
- for 2.0.4, use linkaliasing
Funny! I moved away from Linux mainly because of Library-Hell issues :-)
Library hell exists on all platforms. Running from it is
On Mon, Jul 17, 2006 at 11:21:36AM +0200, Micha Nelissen wrote:
Marco van de Voort wrote:
This has nothing to do with source based vs binary. If e.g. debian renamed
libs tomorrow inside a branch, it would have the same effect.
They can't do that without breaking all other packages in the
On Mon, Jul 17, 2006 at 11:19:22AM +0200, Jonas Maebe wrote:
They refer
to pkgconfig or keep on using the -RELEASE ports branch (which is
security
only),
Of course I can't take a tool that emits gcc parametes seriously
(since
some ad hoc parsing will probably break on the first gcc
On 17 Jul 2006, at 11:59, Marco van de Voort wrote:
It generates ld parameters, not gcc parameters. So you don't have to
parse them unless you want to use an internal linker.
Thnks, will improve the text for the wiki. Not that it changes
much, don't
like an external called from the
On 17 Jul 2006, at 12:21, Daniël Mantione wrote:
That doesn't mean Mac OS X doesn't potentially have the same
library problems
though, since most open source based libraries are not distributed
as a
framework.
IMHO crap like *_config are only tricks used by C people used to work
around
On 17 Jul 2006, at 12:33, Jonas Maebe wrote:
There simply should be no reason
why you want such complexity. A library has a name, you link to it by
name, basta.
A library
can
also exist in at least multiple locations, versions (both ABI-
compatible and -incompatible with previous
Bob wrote:
Funny! I moved away from Linux mainly because of Library-Hell issues :-)
You've to move away from unix then :) I made similiar experiences when porting
FPC to Solaris.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
On Mon, Jul 17, 2006 at 12:16:10PM +0200, Jonas Maebe wrote:
There is no other way to properly support linking to external
libraries, unless you use something like Mac OS X' frameworks (which
does support transparent versioning and multi-version support,
including name changes of
Marco van de Voort wrote:
They can't do that without breaking all other packages in the archive
using this package. They don't get rebuilt automatically AFAIK, and
that's where the difference is IMHO.
I don't understand this. Afaik there is no difference at all. Could you be
more elaborate
On 17 Jul 2006, at 13:42, Marco van de Voort wrote:
That's not the point. The point is that I consider a solution, that
tries to
collect this data automatically, worse than the current situation.
There's no reason why a default fallback to the current system
couldn't be supported.
IOW
Op Mon, 17 Jul 2006, schreef Jonas Maebe:
There's nothing C-specific about libraries, nor about the *config scripts. At
most it would be linker-specific.
There is, those scripts mainly exist because a C compiler cannot determine
the dependencies of a library. I.e. if you like libgtk you
On 17 Jul 2006, at 14:03, Daniël Mantione wrote:
There's nothing C-specific about libraries, nor about the *config
scripts. At
most it would be linker-specific.
There is, those scripts mainly exist because a C compiler cannot
determine
the dependencies of a library. I.e. if you like
On Mon, Jul 17, 2006 at 01:56:38PM +0200, Micha Nelissen wrote:
Marco van de Voort wrote:
They can't do that without breaking all other packages in the archive
using this package. They don't get rebuilt automatically AFAIK, and
that's where the difference is IMHO.
I don't understand
On Mon, Jul 17, 2006 at 01:57:01PM +0200, Jonas Maebe wrote:
That's not the point. The point is that I consider a solution, that
tries to
collect this data automatically, worse than the current situation.
There's no reason why a default fallback to the current system
couldn't be
Marco van de Voort wrote:
On Mon, Jul 17, 2006 at 01:56:38PM +0200, Micha Nelissen wrote:
the library name correctly according to that distro's packaging rules)
then all dependent software is automatically recompiled for the new
version (and name), and thus no one notices any breakages. Except
On 17 Jul 2006, at 14:31, Marco van de Voort wrote:
There's no reason why a default fallback to the current system
couldn't be supported.
If it doesn't exist. But what if it fails?
The current solution also fails from time to time. And there would
switch to disable this gtk-config
1 - 100 of 115 matches
Mail list logo