On Sunday 10 September 2017 02:51:36 fredvs wrote:
> Re-re-re hello Martin.
>
> OK, capito, the crash was because I used the debugger (it is to hard for
> him to deal with audio programs with lot of dsp).
>
> Without debugger --> works like charm.
>
> Many thanks.
>
> I will use your tips for the n
Re-re-re hello Martin.
OK, capito, the crash was because I used the debugger (it is to hard for him
to deal with audio programs with lot of dsp).
Without debugger --> works like charm.
Many thanks.
I will use your tips for the next piece of StrumPract: the recorder.
Fre;D
--
Sent from: http
Re.re hello Martin.
Ok, tested the patch.
Perfect for docking/floating/show/hide forms.
Many thanks,
The only thing is that now playing a file with the Song Player crash the
application.
I will check with previous code what could cause this (tomorrow).
Fre;D
--
Sent from: http://mseide-mse
Ooops, sorry for previous mail:
That worked: >
# git apply layout.patch.
Wow, you worked a lot !
Ha, it seems to need last MSE commit.
OK, I update MSE and test your patch.
Write you later.
Many thanks.
Fre;D
--
Sent from: http://mseide-msegui-talk.13964.n8.nabble.com/
-
Hello Martin.
Here what I did:
Copy layout.patch in /strumpract.
Then in console:
# cd strumpract
# git apply --stat layout.patch
---> 12 files changed, 7642 insertions(+), 7505 deletions(-)
# git apply --check layout.patch
---> OK, no error.
# git am --signoff < layout.patch
---> Patch
-- This is continuation from a other MSE topic --
>>On 2017-09-08 19:18, Martin Schreiber wrote:
>> Free Pascal should allow to define the SONAME source in binding unit -
>> using
>> dlopen()/dlsym() instead is a hack IMHO.
>On 2017-09-08 20:18, Graeme wrote:
>I think so too.
OK, ok, I agre
Hello Martin.
Super clear.
The link.pas file dates from 2002 :
https://old-linux.com
In that age, only Intel x86 operating system and maybe link.pas was designed
to link *.a files.
In that case the thelibrary-dev.so was needed.
I do not know what to do with your patch.
FPC does not want it.
M
On Saturday 09 September 2017 19:15:18 fredvs wrote:
> > I do not understand...
>
> OK, I do understand now.
> So it will not be possible to use ld-linux.so.2 for calling the library
> form where/ when you want.
>
> > Please do not confuse "static" linking and "dynamic"
>
> OK. Let do like this:
>
On Saturday 09 September 2017 19:23:19 fredvs wrote:
> > > Maybe in compiler/link.pas:509 (TLinker.AddSharedCLibrary()).
>
> Procedure TLinker.AddSharedCLibrary(S:TCmdStr);
> begin
> if s='' then
> exit;
> { remove prefix 'lib' }
> if
> Copy(s,1,length(ta
> Please take the attached patch for inspiration.
Wow, thanks Martin.
Will test it tonight.
Write you later.
Fre;D
--
Sent from: http://mseide-msegui-talk.13964.n8.nabble.com/
--
Check out the vibrant tech community
> > Maybe in compiler/link.pas:509 (TLinker.AddSharedCLibrary()).
Procedure TLinker.AddSharedCLibrary(S:TCmdStr);
begin
if s='' then
exit;
{ remove prefix 'lib' }
if
Copy(s,1,length(target_info.sharedclibprefix))=target_info.sharedclibprefix
then
> I do not understand...
OK, I do understand now.
So it will not be possible to use ld-linux.so.2 for calling the library form
where/ when you want.
> Please do not confuse "static" linking and "dynamic"
OK. Let do like this:
"shared/dynamic" linking using ld-linux.so.2:
I will call it "ld dy
Hello Graeme.
For me the most important is that we are not in trouble ;-)
Thanks.
Fre;D
--
Sent from: http://mseide-msegui-talk.13964.n8.nabble.com/
--
Check out the vibrant tech community on one of the world's most
On 2017-09-08 19:18, Martin Schreiber wrote:
Free Pascal should allow to define the SONAME source in binding unit - using
dlopen()/dlsym() instead is a hack IMHO.
I think so too. I source of the problem is FPC, and that is where the
fix should go.
I do applaud Fred for his efforts and energy
On Saturday 09 September 2017 14:49:43 fredvs wrote:
> Re-hello.
>
> Huh, in previous mail, at end please read this:
>
> The last war would be "What is better: libdl.so.2 or ld-linux.so.2 ?
>
> Could it be possible to imagine a different dynlibs.pas ?
> Actual dynlibs.pas is using libdl.so.2.
> Cou
Re-hello.
Huh, in previous mail, at end please read this:
The last war would be "What is better: libdl.so.2 or ld-linux.so.2 ?
Could it be possible to imagine a different dynlibs.pas ?
Actual dynlibs.pas is using libdl.so.2.
Could it be possible to use ld-linux.so.2 instead (with corresponden
> Then the application can not start if the library is not found and
> it can not be compiled if there is no libX11.so -> ibX11.so.6 link.
Of course the "double advantage" works only if buggy "external" was fixed !
;-)
> Maybe in compiler/link.pas:509 (TLinker.AddSharedCLibrary()).
OK, I will
On Saturday 09 September 2017 13:35:18 fredvs wrote:
> Hello Martin.
>
> Do you know where in fpc code (or how to find it) "external" is assigned
> and 'so.n' deleted ?
>
Maybe in compiler/link.pas:509 (TLinker.AddSharedCLibrary()).
Martin
-
On Saturday 09 September 2017 12:53:22 fredvs wrote:
> > Another advantage of ld-linux.so.2 is that it is possible to list the
>
> needed libraries by "ldd ".
>
> Huh, it is what I try to explain: you may use dlopen()/dlsym() and list
> list the needed libraries by "ldd".
> ---> Add in dynamic link
Hello Martin.
Do you know where in fpc code (or how to find it) "external" is assigned and
'so.n' deleted ?
Fre;D
--
Sent from: http://mseide-msegui-talk.13964.n8.nabble.com/
--
Check out the vibrant tech community on
> Another advantage of ld-linux.so.2 is that it is possible to list the
needed libraries by "ldd ".
Huh, it is what I try to explain: you may use dlopen()/dlsym() and list list
the needed libraries by "ldd".
---> Add in dynamic linking code a {$linklib} statement (or Procedure
dummy() ; cdecl; ext
21 matches
Mail list logo