[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Rudolf Seemann
Subject: Re: Dynamic linking of .oct files and symbol names in libcruft (intrp.f in libcruft/villad)
Date: 11 Sep 2003 14:33:54 +0200

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.

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:
        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:
How to fund new projects:
Subscription information:

reply via email to

[Prev in Thread] Current Thread [Next in Thread]