f



MEX problem calling routines in shared library (Linux)

Ok, I have a real strange problem here. The situation is the following:

I create a mex routine which is a layer between MATLAB and my implementation 
code which is contained in a shared library (.so library). So this code is 
linked dynamically at runtime with the mex driver.
In this shared library, I have a function called mempool_create. It is 
defined there and it is called from this shared library.
The problem is that not this mempool_create is being called, but a 
mempool_create routine which is defined in libmwcg_ir.so
So it appears that by coincidense I have chosen a routine name that is also 
defined in another shared library. I would have expected that the 
implementation from my own library would be called, but no, it calls the 
implementation from a totally different and unknown library to me.
I can recompile my library and if I try this with a renamed version of my 
routine, then things work as expected. So it is really the duplicate name 
that is bugging me.

This is of course very dangerous and renaming this function doesn't 
guarantee me that there are no other routines which also have conflicting 
names with again this effect.

So my question is: is there a solution to this problem without renaming the 
routine but making sure that my implementation is called and not one from 
another shared library that is by coincidense also loaded (by MATLAB itself 
probably)?

Note that this is under Linux with matlab version 6.5 (R13)

Any thoughts?

Thanks,

Peter 


0
peno (10)
2/25/2005 10:55:47 PM
comp.soft-sys.matlab 211264 articles. 25 followers. lunamoonmoon (257) is leader. Post Follow

6 Replies
601 Views

Similar Articles

[PageSpeed] 26

Peter Notebaert wrote:

> 
> So my question is: is there a solution to this problem without renaming the 
> routine but making sure that my implementation is called and not one from 
> another shared library that is by coincidense also loaded (by MATLAB itself 
> probably)?

Check out your compiler flags.  I believe with GCC there is something 
like '-B symbolic' or a similar variant which will resolve this for you. 
  Shared libraries all load into the same process space.  The solution 
above seemed to do the trick for me a while back.

	todd
0
2/28/2005 4:58:46 PM
Peter Notebaert wrote:
>
>
> Ok, I have a real strange problem here. The situation is the
> following:
>
> I create a mex routine which is a layer between MATLAB and my
> implementation
> code which is contained in a shared library (.so library). So this
> code is
> linked dynamically at runtime with the mex driver.
> In this shared library, I have a function called mempool_create. It
> is
> defined there and it is called from this shared library.
> The problem is that not this mempool_create is being called, but a
> mempool_create routine which is defined in libmwcg_ir.so
> So it appears that by coincidense I have chosen a routine name that
> is also
> defined in another shared library. I would have expected that the
> implementation from my own library would be called, but no, it
> calls the
> implementation from a totally different and unknown library to me.
> I can recompile my library and if I try this with a renamed version
> of my
> routine, then things work as expected. So it is really the
> duplicate name
> that is bugging me.
>
> This is of course very dangerous and renaming this function doesn't
>
> guarantee me that there are no other routines which also have
> conflicting
> names with again this effect.
>
> So my question is: is there a solution to this problem without
> renaming the
> routine but making sure that my implementation is called and not
> one from
> another shared library that is by coincidense also loaded (by
> MATLAB itself
> probably)?
>
> Note that this is under Linux with matlab version 6.5 (R13)
>
> Any thoughts?

Are you able to make a single MEX file from your wrapper and your
library? This would cause the name resolution to take place on
creation of the MEX file (during the link stage) rather than at run
time.

Alternatively, you could use dlopen() and dlsym() in your MEX file to
explicitly load and resolve your function.
0
3/1/2005 10:17:37 AM
Todd,

Thank you very much for your answer. It solved my problem! The link option
is -Bsymbolic (no spaces, see man ld). Since the linker is invoked via the
gcc compiler, I had to provide the option as -Wl,-Bsymbolic
The -Wl gcc option tells gcc to pass the option -Bsymbolic to the linker.

Again thank you very much for solving this puzzling problem.

Peter


"Todd" <tatkins-nospam@mathworks.com> wrote in message 
news:cvvik6$k9q$1@fred.mathworks.com...
> Peter Notebaert wrote:
>
>>
>> So my question is: is there a solution to this problem without renaming 
>> the routine but making sure that my implementation is called and not one 
>> from another shared library that is by coincidense also loaded (by MATLAB 
>> itself probably)?
>
> Check out your compiler flags.  I believe with GCC there is something like 
> '-B symbolic' or a similar variant which will resolve this for you. Shared 
> libraries all load into the same process space.  The solution above seemed 
> to do the trick for me a while back.
>
> todd 


0
peno (10)
3/1/2005 8:25:44 PM
That was my intermediate solution, but I wanted to use a shared library 
version of my code and not a static library to make it easier to update the 
code. Todd has a solution that makes the shared library work as expected.

Peter

"Steve Amphlett" <Firstname.Lastname@where_I_work.com> wrote in message 
news:eefd314.1@webx.raydaftYaTP...
> Peter Notebaert wrote:
>>
>>
>> Ok, I have a real strange problem here. The situation is the
>> following:
>>
>> I create a mex routine which is a layer between MATLAB and my
>> implementation
>> code which is contained in a shared library (.so library). So this
>> code is
>> linked dynamically at runtime with the mex driver.
>> In this shared library, I have a function called mempool_create. It
>> is
>> defined there and it is called from this shared library.
>> The problem is that not this mempool_create is being called, but a
>> mempool_create routine which is defined in libmwcg_ir.so
>> So it appears that by coincidense I have chosen a routine name that
>> is also
>> defined in another shared library. I would have expected that the
>> implementation from my own library would be called, but no, it
>> calls the
>> implementation from a totally different and unknown library to me.
>> I can recompile my library and if I try this with a renamed version
>> of my
>> routine, then things work as expected. So it is really the
>> duplicate name
>> that is bugging me.
>>
>> This is of course very dangerous and renaming this function doesn't
>>
>> guarantee me that there are no other routines which also have
>> conflicting
>> names with again this effect.
>>
>> So my question is: is there a solution to this problem without
>> renaming the
>> routine but making sure that my implementation is called and not
>> one from
>> another shared library that is by coincidense also loaded (by
>> MATLAB itself
>> probably)?
>>
>> Note that this is under Linux with matlab version 6.5 (R13)
>>
>> Any thoughts?
>
> Are you able to make a single MEX file from your wrapper and your
> library? This would cause the name resolution to take place on
> creation of the MEX file (during the link stage) rather than at run
> time.
>
> Alternatively, you could use dlopen() and dlsym() in your MEX file to
> explicitly load and resolve your function. 


0
peno (10)
3/1/2005 8:27:53 PM
Peter Notebaert wrote:
>
>
> Todd,
>
> Thank you very much for your answer. It solved my problem! The link
> option
> is -Bsymbolic (no spaces, see man ld). Since the linker is invoked
> via the
> gcc compiler, I had to provide the option as -Wl,-Bsymbolic
> The -Wl gcc option tells gcc to pass the option -Bsymbolic to the
> linker.

Let's just hope you don't ever need to port your lib to platforms
that don't have this link option!
0
3/2/2005 8:34:31 AM
Well, let's hope then that these system don't have this problem also so that
the option is not needed anyway. Else I can still use the static library on
these.

Note that I find it still very strange how it behaved:

                    A
+---------------------------+
| Some matlab shared library |
| that contains also                |
| mempool_create                 |
+---------------------------+

                     B
+---------------------------+
| mex driver (shared library)  |
+---------------------------+

                    C
+---------------------------+
| my shared library                |
| that contains                       |
| mempool_create                |
+---------------------------+

So I have three shared libraries here. From MATLAB, I use the mex drivers
that is shared library B.
This calls my shared library C that has the implementation of some routines.

In library C, I do a call to a routine called mempool_create that is also in
library C. However, by coincidense it is also in another shared library A
loaded by MATLAB itself, but that I don't use at all.

The problem was that not the implementation in library C was called, but the
one in A. This is totally illogical to me. If the implementation is in
library C and it is called from library C, then it should always use the
implementation from library C and not from another one.

If I would call this routine from library B, then I can accept that the
system descides itself if it calls the routine from library A or C, but not
when called from C.

This  -Bsymbolic option makes this work as I expect.

My intermediate solution was that library C was a static library.

Peter

"Steve Amphlett" <Firstname.Lastname@where_I_work.com> wrote in message 
news:eefd314.4@webx.raydaftYaTP...
> Peter Notebaert wrote:
>>
>>
>> Todd,
>>
>> Thank you very much for your answer. It solved my problem! The link
>> option
>> is -Bsymbolic (no spaces, see man ld). Since the linker is invoked
>> via the
>> gcc compiler, I had to provide the option as -Wl,-Bsymbolic
>> The -Wl gcc option tells gcc to pass the option -Bsymbolic to the
>> linker.
>
> Let's just hope you don't ever need to port your lib to platforms
> that don't have this link option! 


0
peno (10)
3/3/2005 11:49:27 PM
Reply: