Re: Dynamic linking of .oct files and symbol names in libcruft (intrp.f in libcruft/villad)

[Rudolf Seemann]

Thank you for all replies!

>| If you are using c++, you could include the file with namespace scope
>| around it:
>| 
>| namespace mylib {
>| 
>| #include "mylib.h"
>| 
>| }
>| 
>| which should solve name conflicts.

>If the "foreign" intrp function were in C++, then the name would be
>mangled and the linker wouldn't see the conflict with Octave's intrp
>function which is Fortran.
>jwe

The foreign function is fortran... 

While trying to be more intelligent than my compiler, I wrapped the
foreign function headers in a namespace as you proposed

-------------------------------------------------
in myobject.h:
namespace mylib {
        #include <optimizer.h>
}

in myobject.cpp:
MyObject::optimize()
{
        mylib::optimizeFunctionInFortran(param1, param2);
}
-------------------------------------------------

Since optimizeFunctionInFortran calls several other functions which live
in global namespace, symbol table in my .oct-file tells me:

-------------------------------------------------
address@hidden octave]$ nm -a optimizePendulum.oct | grep intrp
00029118 T intrp_
00000000 a intrp.f
-------------------------------------------------
As expected and undesired the linker made intrp a global symbol again. 

Any other ideas?

Thanks Rudi

PS I liked the namespace idea, that would have been much more
comfortable than renaming functinons in libcruft or my library... but as
life goes the problem remains.





-------------------------------------------------------------
Octave is freely available under the terms of the GNU GPL.

Octave's home on the web:  http://www.octave.org
How to fund new projects:  http://www.octave.org/funding.html
Subscription information:  http://www.octave.org/archive.html
-------------------------------------------------------------