windows.GetProcAddress() vs DynLibs.GetProcAddress()

classic Classic list List threaded Threaded
60 messages Options
123
Reply | Threaded
Open this post in threaded view
|

Re: windows.GetProcAddress() vs DynLibs.GetProcAddress()

fredvs

> 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  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: windows.GetProcAddress() vs DynLibs.GetProcAddress()

Marco van de Voort
In reply to this post by fredvs
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  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: windows.GetProcAddress() vs DynLibs.GetProcAddress()

fredvs
> 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  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: windows.GetProcAddress() vs DynLibs.GetProcAddress()

Ludo Brands
In reply to this post by fredvs
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  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: windows.GetProcAddress() vs DynLibs.GetProcAddress()

fredvs

> 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  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: windows.GetProcAddress() vs DynLibs.GetProcAddress()

fredvs
In reply to this post by Ludo Brands

> 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 $00007FE493CE2AE8:
EAccessViolation: Access violation
  $00007FE493CE2AE8
------------------
(program exited with code: 217)



_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: windows.GetProcAddress() vs DynLibs.GetProcAddress()

Marco van de Voort
In reply to this post by fredvs
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  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: windows.GetProcAddress() vs DynLibs.GetProcAddress()

fredvs
> 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  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: windows.GetProcAddress() vs DynLibs.GetProcAddress()

fredvs
In reply to this post by Marco van de Voort

> 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  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: windows.GetProcAddress() vs DynLibs.GetProcAddress()

Ludo Brands
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  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: windows.GetProcAddress() vs DynLibs.GetProcAddress()

Ewald-2

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  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: win64 / zipper & fphttpclient

philippe sylvain levi
In reply to this post by fredvs

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  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: windows.GetProcAddress() vs DynLibs.GetProcAddress()

fredvs
In reply to this post by Ludo Brands

> 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  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: windows.GetProcAddress() vs DynLibs.GetProcAddress()

fredvs
In reply to this post by Ewald-2

> 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.
SOUNDTOUCHDLL_API void __cdecl soundtouch_flush(HANDLE h);
 
/// Adds 'numSamples' pcs of samples from the 'samples' memory position into
/// the input of the object. Notice that sample rate _has_to_ be set before
/// calling this function, otherwise throws a runtime_error exception.
SOUNDTOUCHDLL_API void __cdecl soundtouch_putSamples(HANDLE h, 
        const float *samples,       ///< Pointer to sample buffer.
        unsigned int numSamples     ///< Number of samples in buffer. Notice
                                    ///< that in case of stereo-sound a single sample
                                    ///< contains data for both channels.
        );
 
/// Clears all the samples in the object's output and internal processing
/// buffers.
SOUNDTOUCHDLL_API void __cdecl soundtouch_clear(HANDLE h);
 
/// Changes a setting controlling the processing system behaviour. See the
/// 'SETTING_...' defines for available setting ID's.
/// 
/// \return 'TRUE' if the setting was succesfully changed
SOUNDTOUCHDLL_API BOOL __cdecl soundtouch_setSetting(HANDLE h, 
                int settingId,   ///< Setting ID number. see SETTING_... defines.
                int value        ///< New setting value.
                );
 
/// Reads a setting controlling the processing system behaviour. See the
/// 'SETTING_...' defines for available setting ID's.
///
/// \return the setting value.
SOUNDTOUCHDLL_API int __cdecl soundtouch_getSetting(HANDLE h, 
                          int settingId    ///< Setting ID number, see SETTING_... defines.
                );
 
 
/// Returns number of samples currently unprocessed.
SOUNDTOUCHDLL_API unsigned int __cdecl soundtouch_numUnprocessedSamples(HANDLE h);
 
/// Adjusts book-keeping so that given number of samples are removed from beginning of the 
/// sample buffer without copying them anywhere. 
///
/// Used to reduce the number of samples in the buffer when accessing the sample buffer directly
/// with 'ptrBegin' function.
SOUNDTOUCHDLL_API unsigned int __cdecl soundtouch_receiveSamples(HANDLE h, 
            float *outBuffer,           ///< Buffer where to copy output samples.
            unsigned int maxSamples     ///< How many samples to receive at max.
            );
 
/// Returns number of samples currently available.
SOUNDTOUCHDLL_API unsigned int __cdecl soundtouch_numSamples(HANDLE h);
 
/// Returns nonzero if there aren't any samples available for outputting.
SOUNDTOUCHDLL_API int __cdecl soundtouch_isEmpty(HANDLE h);
 
#endif  // _SoundTouchDLL_h_
 


_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: windows.GetProcAddress() vs DynLibs.GetProcAddress()

Ewald-2
<base href="x-msg://3/">
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  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: windows.GetProcAddress() vs DynLibs.GetProcAddress()

fredvs
In reply to this post by fredvs
> 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  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: windows.GetProcAddress() vs DynLibs.GetProcAddress()

fredvs
In reply to this post by Ewald-2
>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  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: windows.GetProcAddress() vs DynLibs.GetProcAddress()

fredvs
In reply to this post by Ludo Brands

> 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  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: windows.GetProcAddress() vs DynLibs.GetProcAddress()

Ewald-2
In reply to this post by fredvs
<base href="x-msg://7/">
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  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: windows.GetProcAddress() vs DynLibs.GetProcAddress()

fredvs
Yep, yep, yep, i get it...

I will (try) to explain the thing...
The error comes mainly because i was focused on SoundTouchDLL.h. (Thanks to Ludo).

That wrapper is for windows only.

Before to call a DSP-buffer-procedure, you must do :
FHandle := soundtouch_createInstance();

But the result of nm libSoundTouch.so gives 3 different soundtouch_createInstance() :

_ZN10soundtouch14TransposerBase11newInstanceEv
_ZN10soundtouch9FIRFilter11newInstanceEv
_ZN10soundtouch9TDStretch11newInstanceEv

The same (for example) for setChannels :

_ZN10soundtouch14TransposerBase11setChannelsEi
_ZN10soundtouch9TDStretch11setChannelsEi
_ZN10soundtouch14RateTransposer11setChannelsEi

And after creating new instance, you must use the procedure of the kind of instance :
_ZN10soundtouch9TDStretch11newInstanceEv
with _ZN10soundtouch9TDStretch11setChannelsEi

And all the procedures defined by SoundTouchDLL.h are not working because the "general" function soundtouch_createInstance() is not part of the library ( or i do not find it ) , all the "general" soundtouch procedure cannot work :

ZN10soundtouch10SoundTouch11setChannelsEj (and all the "general" others)
______________

Now, conclusion of that hard battle :

1) With fpc, there is ALWAYS a solution.
2) Without the help of Ludo, Ewald and Marco i never would find that solution.
3) If you want create pascal wrappers I highly recommend to use "nm the_problematic_lib.so" and analyse carefully the result.
4) Dynlibs.pas is working perfectly and (for me) one of the most important part of fpc (because it opens fpc to other worlds).

Biggest thank for helping.
Have perfect days.

PS : I will post the definitive wrapper when everything is working.

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
123