Re: [fpc-pascal] windows.GetProcAddress() vs DynLibs.GetProcAddress()
On 17 Jan 2014, at 21:14, Fred van Stappen wrote: > >Ha, then you use/compiled a different version. Since a `extern "C"` preserves > > the symbol name (that is the trick I use to link in a lot of external C++ > > code: > >just put extern "C" in front of the symbol). or it could be that I am > >completely > >missing something here. [for example: is the symbol `DLL_EXPORTS` defined at > >compile time?] > > Hum, "just put extern "C" in front of the symbol" (no capito ;-( ) What I'm trying to say is that if there is `extern "C"` in front of a symbol, C++ won't mangle the name. In the cpp file you attached in one of your previous mails, [assuming a C++ compiler] this is the case as per the expansion of the macro `SOUNDTOUCHDLL_API`; on one condition: that `DLL_EXPORTS` is defined. [hint: read ahead to the second part first as it might just solve your problem] Since you see mangled names, there must be an error or version mismatch somewhere in your build of the library. So I thought that perhaps you are using a compiled version of the library that still uses stdcall instead of cdecl. To get closer to the bug, try the following: - Compile with debug symbols everwhere (there is no such thing as overkill ;-) ) - Run your program in gdb and get a backtrace (`bt` on the command line of gdb), if the crash occurs at the end of the function in the library, or just after the call, then it might be a calling convention issue. If I am informed correctly (see http://stackoverflow.com/questions/3404372/stdcall-and-cdecl) then the difference between stdcall and cdecl lies in who cleans up the stack. A mismatch results in the stack being cleaned up twice or not at all. Both rather inconvenient to normal program flow. If this is the case, try changing calling conventions. > > PS2 : We gonna get it, im sure... [The Second Part -->] Well, it seems I have found something interresting here (as already suggested by Marco); you don't define THandle in your library wrapper. THandle is defined as a longint (http://www.freepascal.org/docs-html/rtl/system/thandle.html), but you need a pointer. Try putting `Type THandle = pointer;` somewhere before the first usage of this type in your library wrapper. -- Ewald ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] windows.GetProcAddress() vs DynLibs.GetProcAddress()
> That routine is defined in SoundTouchDLL.cpp which is the windows dll > wrapper. Do you have the linux equivalent? Oops, im full of doubt now... Do you think the SoundTouchDLL.h wrapper is for Windows only ( and, yes, the old wrapper uses stdcall (who is windows only)). And for linux how does the programmers to link to the library without wrapper ? Im loosed... ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] windows.GetProcAddress() vs DynLibs.GetProcAddress()
>Ha, then you use/compiled a different version. Since a `extern "C"` preserves > the symbol name (that is the trick I use to link in a lot of external C++ > code: >just put extern "C" in front of the symbol). or it could be that I am >completely >missing something here. [for example: is the symbol `DLL_EXPORTS` defined at >compile time?] Hum, "just put extern "C" in front of the symbol" (no capito ;-( ) PS : Here the prototype-code of the Linux Pascal Wrapper i use : >> https://sites.google.com/site/fiensprototyping/soundtouch_linux.zip PS2 : We gonna get it, im sure... ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] windows.GetProcAddress() vs DynLibs.GetProcAddress()
On 17 Jan 2014, at 20:40, Fred van Stappen wrote: > > Yep, there is a brand new wrapper from trunk : Ha, then you use/compiled a different version. Since a `extern "C"` preserves the symbol name (that is the trick I use to link in a lot of external C++ code: just put extern "C" in front of the symbol). or it could be that I am completely missing something here. [for example: is the symbol `DLL_EXPORTS` defined at compile time?] -- Ewald ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] windows.GetProcAddress() vs DynLibs.GetProcAddress()
> Yep, there is a brand new wrapper from trunk : Of course, all the tests i have done are with that new wrapper... ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] windows.GetProcAddress() vs DynLibs.GetProcAddress()
> Note one detail: it is declared there as __stdcall, not as __cdecl, so
> perhaps this has something to do with it?
>
> @Fred: Also note that the type HANDLE is defined there as a pointer, so [as a
> sanity test of sorts] sizeof(Handle {in pascal}) should be equal to
> sizeof(HANDLE /*in C/C++*/).
>
> --
> Ewald
Yep, there is a brand new wrapper from trunk :
//
///
/// SoundTouch DLL wrapper - wraps SoundTouch routines into a Dynamic Load
/// Library interface.
///
/// Author: Copyright (c) Olli Parviainen
/// Author e-mail : oparviai 'at' iki.fi
/// SoundTouch WWW: http://www.surina.net/soundtouch
///
//
// $Id: SoundTouchDLL.h 94 2010-12-12 18:28:49Z oparviai $
//
//
// License :
//
// SoundTouch audio processing library
// Copyright (c) Olli Parviainen
//
// This library is free software; you can redistribute it and/or
// modify it under the terms of the GNU Lesser General Public
// License as published by the Free Software Foundation; either
// version 2.1 of the License, or (at your option) any later version.
//
// This library is distributed in the hope that it will be useful,
// but WITHOUT ANY WARRANTY; without even the implied warranty of
// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
// Lesser General Public License for more details.
//
// You should have received a copy of the GNU Lesser General Public
// License along with this library; if not, write to the Free Software
// Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
//
#ifndef _SoundTouchDLL_h_
#define _SoundTouchDLL_h_
#ifdef __cplusplus
#ifdef DLL_EXPORTS
#define SOUNDTOUCHDLL_API extern "C" __declspec(dllexport)
#else
#define SOUNDTOUCHDLL_API extern "C" __declspec(dllimport)
#endif
#else
#ifdef DLL_EXPORTS
#define SOUNDTOUCHDLL_API __declspec(dllexport)
#else
#define SOUNDTOUCHDLL_API __declspec(dllimport)
#endif
#endif // __cplusplus
typedef void * HANDLE;
/// Create a new instance of SoundTouch processor.
SOUNDTOUCHDLL_API HANDLE __cdecl soundtouch_createInstance();
/// Destroys a SoundTouch processor instance.
SOUNDTOUCHDLL_API void __cdecl soundtouch_destroyInstance(HANDLE h);
/// Get SoundTouch library version string
SOUNDTOUCHDLL_API const char *__cdecl soundtouch_getVersionString();
/// Get SoundTouch library version string - alternative function for
/// environments that can't properly handle character string as return value
SOUNDTOUCHDLL_API void __cdecl soundtouch_getVersionString2(char*
versionString, int bufferSize);
/// Get SoundTouch library version Id
SOUNDTOUCHDLL_API unsigned int __cdecl soundtouch_getVersionId();
/// Sets new rate control value. Normal rate = 1.0, smaller values
/// represent slower rate, larger faster rates.
SOUNDTOUCHDLL_API void __cdecl soundtouch_setRate(HANDLE h, float newRate);
/// Sets new tempo control value. Normal tempo = 1.0, smaller values
/// represent slower tempo, larger faster tempo.
SOUNDTOUCHDLL_API void __cdecl soundtouch_setTempo(HANDLE h, float newTempo);
/// Sets new rate control value as a difference in percents compared
/// to the original rate (-50 .. +100 %);
SOUNDTOUCHDLL_API void __cdecl soundtouch_setRateChange(HANDLE h, float
newRate);
/// Sets new tempo control value as a difference in percents compared
/// to the original tempo (-50 .. +100 %);
SOUNDTOUCHDLL_API void __cdecl soundtouch_setTempoChange(HANDLE h, float
newTempo);
/// Sets new pitch control value. Original pitch = 1.0, smaller values
/// represent lower pitches, larger values higher pitch.
SOUNDTOUCHDLL_API void __cdecl soundtouch_setPitch(HANDLE h, float newPitch);
/// Sets pitch change in octaves compared to the original pitch
/// (-1.00 .. +1.00);
SOUNDTOUCHDLL_API void __cdecl soundtouch_setPitchOctaves(HANDLE h, float
newPitch);
/// Sets pitch change in semi-tones compared to the original pitch
/// (-12 .. +12);
SOUNDTOUCHDLL_API void __cdecl soundtouch_setPitchSemiTones(HANDLE h, float
newPitch);
/// Sets the number of channels, 1 = mono, 2 = stereo
SOUNDTOUCHDLL_API void __cdecl soundtouch_setChannels(HANDLE h, unsigned int
numChannels);
/// Sets sample rate.
SOUNDTOUCHDLL_API void __cdecl soundtouch_setSampleRate(HANDLE h, unsigned int
srate);
/// Flushes the last samples from the processing pipeline to the output.
/// Clears also the internal processing buffers.
//
/// Note: This function is meant for extracting the last samples of a sound
/// stream. This function may introduce additional blank samples in the end
/// of the sound stream, and thus it's not recommended to call this function
/// in the middle of a sound stream.
SOUNDTOUCHD
Re: [fpc-pascal] windows.GetProcAddress() vs DynLibs.GetProcAddress()
> That routine is defined in SoundTouchDLL.cpp which is the windows dll > wrapper. Do you have the linux equivalent? > > Ludo PS : For new new arriving : SoundTouchDLL.cpp is part of SoundTouch, a audio processing library : >> http://www.surina.net/soundtouch/download.html @ Ludo : In /source/SoundTouch/ there is SoundTouch.cpp I have compiled the package in Linux like said in readme with : ./bootstrap" script, then configure, make all, sudo make install. And i get a libSoundTouch.so in usr/local/lib. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] win64 / zipper & fphttpclient
I have implemented web access and unzipping of archives in my program. Compiling perfectly targetting win32. But when I wanted to mail a win64 version ... using ppcrossx64 ... it did not find zipper & fphttpclient units ... Could anyone tell me how to make those units (and related ones if any) available for ppcrossx64? Thanks Philippe S. Lévi ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] windows.GetProcAddress() vs DynLibs.GetProcAddress()
On 17 Jan 2014, at 17:25, Ludo Brands wrote:
> On 01/17/2014 05:09 PM, Fred van Stappen wrote:
>>
>>> I don't know if the Handle type in the header is defined by the C++
>> compiler
>>> or by the package itself. Consult their respective documentation for more
>>> info.
>>
>> Here declaration of create instance :
>>
>> // Create a new instance of SoundTouch processor.
>> SOUNDTOUCHDLL_API HANDLE __cdecl soundtouch_createInstance();
>>
>>
>>
>
> That routine is defined in SoundTouchDLL.cpp which is the windows dll
> wrapper.
Note one detail: it is declared there as __stdcall, not as __cdecl, so perhaps
this has something to do with it?
@Fred: Also note that the type HANDLE is defined there as a pointer, so [as a
sanity test of sorts] sizeof(Handle {in pascal}) should be equal to
sizeof(HANDLE /*in C/C++*/).
--
Ewald
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] windows.GetProcAddress() vs DynLibs.GetProcAddress()
On 01/17/2014 05:09 PM, Fred van Stappen wrote: > >> I don't know if the Handle type in the header is defined by the C++ > compiler >> or by the package itself. Consult their respective documentation for more >> info. > > Here declaration of create instance : > > // Create a new instance of SoundTouch processor. > SOUNDTOUCHDLL_API HANDLE __cdecl soundtouch_createInstance(); > > > That routine is defined in SoundTouchDLL.cpp which is the windows dll wrapper. Do you have the linux equivalent? Ludo ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] windows.GetProcAddress() vs DynLibs.GetProcAddress()
> I don't know if the Handle type in the header is defined by the C++ compiler > or by the package itself. Consult their respective documentation for more > info. Here declaration of create instance : // Create a new instance of SoundTouch processor. SOUNDTOUCHDLL_API HANDLE __cdecl soundtouch_createInstance(); ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] windows.GetProcAddress() vs DynLibs.GetProcAddress()
> Writeln(sizeof(THandle)); // for console apps FHandle := soundtouch_createInstance(); writeln(FHandle); Writeln(sizeof(FHandle)); Gives that result : 10321232 4 > I don't know if the Handle type in the header is defined by the > C++ compiler or by the package itself. > Consult their respective documentation for more info. ? ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] windows.GetProcAddress() vs DynLibs.GetProcAddress()
In our previous episode, Fred van Stappen said: > > Handle is not defined on Linux. Many libraries emulate some handle type, but > > it depends on the vendor if they make handle 32-bit or 64-bit. > > > > Make sure that sizeof(HANDLE) in C++ matches sizeof(THandle) in FPC. Adjust > > the type you use at the FPC side if necessary. > > > Yep, Marco, many thanks... > > Hum, : > > Make sure that sizeof(HANDLE) in C++ matches sizeof(THandle) in FPC. > >Adjust the type you use at the FPC side if necessary. > > How to do that ? (sorry, i do not understand) Writeln(sizeof(THandle)); // for console apps somememo.lines.add(sizeof(THandle)); // for gui apps. I don't know if the Handle type in the header is defined by the C++ compiler or by the package itself. Consult their respective documentation for more info. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] windows.GetProcAddress() vs DynLibs.GetProcAddress()
> What is the value of the handle that was returned?
>
> Ludo
Re-hello Ludo.
That code :
if ST_Load('/home/fred/dynlib_vs_windows/libSoundTouch.so') then
writeln('libSoundTouch.so loaded');
if FHandle <> NilHandle then soundtouch_clear(FHandle);
FHandle := soundtouch_createInstance();
writeln(FHandle);
FVersionID := soundtouch_getVersionId();
writeln(FVersionID);
FVersionString := StrPas(soundtouch_getVersionString());
writeln(FVersionString);
soundtouch_setChannels(FHandle, 2);
writeln('OK SetChannels');
soundtouch_setSampleRate(FHandle, 44100);
writeln('OK SampleRate');
> Gives that result :
libSoundTouch.so loaded
22351184
10800
1.8.0
OK SetChannels
An unhandled exception occurred at $7FE493CE2AE8:
EAccessViolation: Access violation
$7FE493CE2AE8
--
(program exited with code: 217)
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] windows.GetProcAddress() vs DynLibs.GetProcAddress()
> On 01/17/2014 03:55 PM, Fred van Stappen wrote:
> >
> >> > I run nm and find the name of the procedures ( PS : without
> > nm-Ewald's tip, you must be a high soothsayer to find it)
> >> > For example, a C called procedure : soundtouch_getVersionString()
> > becomes : _ZN10soundtouch10SoundTouch16getVersionStringEv() !!!
> >> >
> >>
> >> The _ZN10soundtouch10SoundTouch16getVersionStringEv name mangling
> >> suggests that this is a C++ lib, not a C lib. Generally speaking, you
> >> can't call C++ libs from fpc.
> >>
> >> Ludo
> >
> > Yep, Ludo, many thanks to take care but...
> >
> > I have a test program who use some procedures to test , for example :
> >
> > FVersionID := soundtouch_getVersionId();
> > FVersionString := StrPas(soundtouch_getVersionString());
> >
> > writeln(FVersionID);
> > writeln(FVersionString);
> >
> Result :
> >
> >> 10800
> >> 1.8.0
> >
> > So, it seems to work...
> >
> > Those procedures are declared as this :
> >
> > Pointer(soundtouch_getVersionId):= GetProcAddress(LibHandle,
> > Pchar('_ZN10soundtouch10SoundTouch12getVersionIdEv'));
> >
> > Pointer(soundtouch_getVersionString):=
> > GetProcAddress(LibHandle,Pchar('_ZN10soundtouch10SoundTouch16getVersionStringEv'));
> >
> >
> >
> That are functions without any parameters that seemingly don't do a lot.
> Do you have any function working that takes a handle as a parameter?
> What is the value of the handle that was returned?
Yep Ludo, thanks to answer and...
Indeed, all the functions without any parameters are working.
And all the other must be initialized with Soundtouch_setSampleRate(FHandle,
samrate);
And, because it does not work, i cannot try the other procedures...
PS : FHandle := soundtouch_createInstance();
Seems to work (i do not get error message)
and this one works too :
soundtouch_setChannels(FHandle, 2);
but this no :
soundtouch_setSampleRate(FHandle, 44100);
And without to set sample-rate, all other procedures are not working...
Many thanks
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] windows.GetProcAddress() vs DynLibs.GetProcAddress()
On 01/17/2014 03:55 PM, Fred van Stappen wrote:
>
>> > I run nm and find the name of the procedures ( PS : without
> nm-Ewald's tip, you must be a high soothsayer to find it)
>> > For example, a C called procedure : soundtouch_getVersionString()
> becomes : _ZN10soundtouch10SoundTouch16getVersionStringEv() !!!
>> >
>>
>> The _ZN10soundtouch10SoundTouch16getVersionStringEv name mangling
>> suggests that this is a C++ lib, not a C lib. Generally speaking, you
>> can't call C++ libs from fpc.
>>
>> Ludo
>
> Yep, Ludo, many thanks to take care but...
>
> I have a test program who use some procedures to test , for example :
>
> FVersionID := soundtouch_getVersionId();
> FVersionString := StrPas(soundtouch_getVersionString());
>
> writeln(FVersionID);
> writeln(FVersionString);
>
Result :
>
>> 10800
>> 1.8.0
>
> So, it seems to work...
>
> Those procedures are declared as this :
>
> Pointer(soundtouch_getVersionId):= GetProcAddress(LibHandle,
> Pchar('_ZN10soundtouch10SoundTouch12getVersionIdEv'));
>
> Pointer(soundtouch_getVersionString):=
> GetProcAddress(LibHandle,Pchar('_ZN10soundtouch10SoundTouch16getVersionStringEv'));
>
>
>
That are functions without any parameters that seemingly don't do a lot.
Do you have any function working that takes a handle as a parameter?
What is the value of the handle that was returned?
Ludo
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] windows.GetProcAddress() vs DynLibs.GetProcAddress()
> Subject: Re: [fpc-pascal] windows.GetProcAddress() vs DynLibs.GetProcAddress()
>
> In our previous episode, Fred van Stappen said:
> > I have only a problem with one procedure:
> >
> > This c procedure is declared as this :
> > SOUNDTOUCHDLL_API void __cdecl soundtouch_setSampleRate(HANDLE h, unsigned
> > int srate);
> >
> > And i translate it like that :
> >
> > soundtouch_setSampleRate : procedure(h : THandle; srate : cardinal); cdecl;
> > and for dynamic-loading :
> > Pointer(soundtouch_setSampleRate):= GetProcAddress(LibHandle,
> > Pchar('_ZN10soundtouch10SoundTouch13setSampleRateEj'));
> >
> > Sadly i get that message when i try to load that procedure :
>
> Handle is not defined on Linux. Many libraries emulate some handle type, but
> it depends on the vendor if they make handle 32-bit or 64-bit.
>
> Make sure that sizeof(HANDLE) in C++ matches sizeof(THandle) in FPC. Adjust
> the type you use at the FPC side if necessary.
Yep, Marco, many thanks...
Hum, :
> Make sure that sizeof(HANDLE) in C++ matches sizeof(THandle) in FPC.
>Adjust the type you use at the FPC side if necessary.
How to do that ? (sorry, i do not understand)
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] windows.GetProcAddress() vs DynLibs.GetProcAddress()
In our previous episode, Fred van Stappen said:
> I have only a problem with one procedure:
>
> This c procedure is declared as this :
> SOUNDTOUCHDLL_API void __cdecl soundtouch_setSampleRate(HANDLE h, unsigned
> int srate);
>
> And i translate it like that :
>
> soundtouch_setSampleRate : procedure(h : THandle; srate : cardinal); cdecl;
> and for dynamic-loading :
> Pointer(soundtouch_setSampleRate):= GetProcAddress(LibHandle,
> Pchar('_ZN10soundtouch10SoundTouch13setSampleRateEj'));
>
> Sadly i get that message when i try to load that procedure :
Handle is not defined on Linux. Many libraries emulate some handle type, but
it depends on the vendor if they make handle 32-bit or 64-bit.
Make sure that sizeof(HANDLE) in C++ matches sizeof(THandle) in FPC. Adjust
the type you use at the FPC side if necessary.
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] windows.GetProcAddress() vs DynLibs.GetProcAddress()
> I only have problem with :
> _ZN10soundtouch10SoundTouch16getVersionStringEv()...
Ooops, have to read :
I only have problem with :
Pointer(soundtouch_setSampleRate):= GetProcAddress(LibHandle,
Pchar('_ZN10soundtouch10SoundTouch13setSampleRateEj'));
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] windows.GetProcAddress() vs DynLibs.GetProcAddress()
> > I run nm and find the name of the procedures ( PS : without nm-Ewald's tip,
> > you must be a high soothsayer to find it)
> > For example, a C called procedure : soundtouch_getVersionString() becomes :
> > _ZN10soundtouch10SoundTouch16getVersionStringEv() !!!
> >
>
> The _ZN10soundtouch10SoundTouch16getVersionStringEv name mangling
> suggests that this is a C++ lib, not a C lib. Generally speaking, you
> can't call C++ libs from fpc.
>
> Ludo
Yep, Ludo, many thanks to take care but...
I have a test program who use some procedures to test , for example :
FVersionID := soundtouch_getVersionId();
FVersionString := StrPas(soundtouch_getVersionString());
writeln(FVersionID);
writeln(FVersionString);
>>> Result :
> 10800
> 1.8.0
So, it seems to work...
Those procedures are declared as this :
Pointer(soundtouch_getVersionId):= GetProcAddress(LibHandle,
Pchar('_ZN10soundtouch10SoundTouch12getVersionIdEv'));
Pointer(soundtouch_getVersionString):=
GetProcAddress(LibHandle,Pchar('_ZN10soundtouch10SoundTouch16getVersionStringEv'));
I only have problem with :
_ZN10soundtouch10SoundTouch16getVersionStringEv()...
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] windows.GetProcAddress() vs DynLibs.GetProcAddress()
On 01/17/2014 03:16 PM, Fred van Stappen wrote: > > I run nm and find the name of the procedures ( PS : without nm-Ewald's tip, > you must be a high soothsayer to find it) > For example, a C called procedure : soundtouch_getVersionString() becomes : > _ZN10soundtouch10SoundTouch16getVersionStringEv() !!! > The _ZN10soundtouch10SoundTouch16getVersionStringEv name mangling suggests that this is a C++ lib, not a C lib. Generally speaking, you can't call C++ libs from fpc. Ludo ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] windows.GetProcAddress() vs DynLibs.GetProcAddress()
Hello.
Thanks to Mister Hinst, i was able to load and run, in Windows, with
dynlib.pas, SoundTouch.dll. Perfect and re-thanks.
Now, i begin a other hard battle : load and run in Linux, libSoundTouch.so.
With the extremely helpful message of Mister Ewald :> Try to find the names of
the symbols defined in the shared object (nm comes to mind).
I run nm and find the name of the procedures ( PS : without nm-Ewald's tip, you
must be a high soothsayer to find it)
For example, a C called procedure : soundtouch_getVersionString() becomes :
_ZN10soundtouch10SoundTouch16getVersionStringEv() !!!
And, believe it or not... it works...
I have only a problem with one procedure:
This c procedure is declared as this :
SOUNDTOUCHDLL_API void __cdecl soundtouch_setSampleRate(HANDLE h, unsigned int
srate);
And i translate it like that :
soundtouch_setSampleRate : procedure(h : THandle; srate : cardinal); cdecl;
and for dynamic-loading :
Pointer(soundtouch_setSampleRate):= GetProcAddress(LibHandle,
Pchar('_ZN10soundtouch10SoundTouch13setSampleRateEj'));
Sadly i get that message when i try to load that procedure :
An unhandled exception occurred at $7F7D76D61AE8:
EAccessViolation: Access violation $7F7D76D61AE8
(program exited with code: 217)
Does somebody have some light for this ?
Many thanks.
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Can Delphi load a small function of a shared lib written in Free Pascal 2.6.2?
I suggest you use COM interfaces to use FPC objects from Delphi code. While FPC class instance memory layout differs from Delphi class instance memory layout, COM interface instances should have identical memory layouts; so they should be accessible from Delphi code 17.01.2014, 04:31, "silvioprog" : > 2014/1/16 Michael Van Canneyt > On Thu, 16 Jan 2014, > Michael Van Canneyt wrote:> On Thu, 16 Jan 2014, silvioprog wrote: Hello, On Windows, I'm trying to serialize an object to JSON in Delphi 7, using FPC functions linked in a shared lib. I'm sendind a small demo in attached. To test it is very easy: 1. compile the libfpserializer.lpr file; 2. copy the generated lib to the demo/lazarus_ok folder; 3. copy the generated lib to the demo/delphi_bug folder; Now, compile the Lazarus project in "lazarus_ok" folder, compile, run and see that it works fine. Now, compile the Delphi project in "delphi_bug" folder, compile, run and see a bizzare bug that kills the app. So, in Delphi 7, its possible to consume a DLL written in Free Pascal? >>> >>> You cannot mix Delphi objects with FPC objects. >>> >>> They have a different memory layout, the RTTI is different etc. >>> So what you try to do is not possible. >> >> I have somewhere a version of TJSONStreamer which uses SuperObject to write >> the JSON. >> If you want I can try to dig it up somewhere. >> >> Michael. > > Very good friend. I want, and it will be very useful to me. Thank you! :) > > -- > Silvio Clécio > My public projects - github.com/silvioprog > > , > ___ > fpc-pascal maillist - fpc-pascal@lists.freepascal.org > http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] DecimalSeparator automatic change ?
Michael Van Canneyt wrote / napísal(a): On Fri, 17 Jan 2014, LacaK wrote: Hi, I have strange problem, I have application on Windows 2012 Server, where is set locale to Slovak (DecimalSeparator is comma) In my application in DataModuleCreate I explicitly set FormatSettings.DecimalSeparator='.' (dot) All works as expected (decimal numbers are formated with "dot"), but after some time (hours) when application runs, DecimalSeparator changes back to "comma" ? Is it possible ? AFAIK International settings are initialised once in sysutils initialization section, or are they reevaluated later ? They are initialized once in FPC. But there is a windows message that notifies applications when the settings change: http://stackoverflow.com/questions/7385357/window-message-notification-language-and-locale Maybe lazarus picks it up. Thank you Michael, it is exactly so. Lazarus catch WM_SETTINGCHANGE and calls Application.IntfSettingChange which calls GetFormatSettings in SysUtils It can be switched off by setting Application.UpdateFormatSettings:=False; Interesting ... Thanks -Laco. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] DecimalSeparator automatic change ?
On Fri, 17 Jan 2014, LacaK wrote: Hi, I have strange problem, I have application on Windows 2012 Server, where is set locale to Slovak (DecimalSeparator is comma) In my application in DataModuleCreate I explicitly set FormatSettings.DecimalSeparator='.' (dot) All works as expected (decimal numbers are formated with "dot"), but after some time (hours) when application runs, DecimalSeparator changes back to "comma" ? Is it possible ? AFAIK International settings are initialised once in sysutils initialization section, or are they reevaluated later ? They are initialized once in FPC. But there is a windows message that notifies applications when the settings change: http://stackoverflow.com/questions/7385357/window-message-notification-language-and-locale Maybe lazarus picks it up. Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
[fpc-pascal] DecimalSeparator automatic change ?
Hi, I have strange problem, I have application on Windows 2012 Server, where is set locale to Slovak (DecimalSeparator is comma) In my application in DataModuleCreate I explicitly set FormatSettings.DecimalSeparator='.' (dot) All works as expected (decimal numbers are formated with "dot"), but after some time (hours) when application runs, DecimalSeparator changes back to "comma" ? Is it possible ? AFAIK International settings are initialised once in sysutils initialization section, or are they reevaluated later ? Thanks -Laco. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
