My understanding of RTLD_DEEP_BIND on linux is that if you have a function A() in your main program, and two functions A() and B() in a dynamically linked library (call it lib) where B is defined as:
B()
{
A();
}
Then a call to B() would ALWAYS end up calling A from the library. Is this the job that RTLD_FIRST does on a mac? Sorry - I am confused by the docs.
What RTLD_DEEPBIND seems to do is the default on OS X. OS X uses something called two-level namespace for dynamic libraries, by default. (You can force the use of flat namespaces either at link time or load time.) With two-level namespace, symbol references record not only the symbol name but the library with which the symbol was resolved at link time. Then, at load time, the symbol is only resolved against that same library.
No. RTLD_FIRST is simply a flag that affects how dlsym behaves when called with the resulting handle, while RTLD_DEEPBIND affects how symbols are resolved when loading the library. They're both rather poorly documented, but that's the information I found base on the man pages for OSX and Linux.
Related
In Tcl, namespace eval <ns> <script> can be used to execute the <script> in the given namespace <ns>, e.g. namespace eval ns1 {set x 123}.
Is there a way in Tcl to activate a namespace such that the subsequent commands are executed within this namespace, and maybe later deactivate it? Fictive code:
namespace activate ns1
set x 123
namespace deactivate ns1
No. Commands are always executed in the current namespace.
You could hack something together for interactive use (namespace is a built-in ensemble command so you can add to its map, and you can have your own REPL without too much work that wraps things in namespace eval at the right point) but that isn't going to be respected particularly by saved scripts.
If you just want this to make commands (including procedures and classes) in a namespace more conveniently available, you can set a namespace path, which is a list of namespaces to resolve command names in (after the current namespace and before the global namespace; at the global level it is effectively just "after the global namespace".) It doesn't change where the things you define are made by default, and doesn't affect the lookup or either variables or namespaces. The path works by setting up a command resolver; the fixed locations of the current and global namespaces in the path resulted in the greatest compatibility with existing code in manual testing...
For completeness... There are variable resolvers as a concept as well, but they're very hard to use (and deeply strange, and called at odd times) and really aren't recommended for anyone not diving very deep. They're not in the public language API except in one place in a very limited way that isn't helpful to your question. They mostly won't help you with where variables are created anyway.
I know that you can make a function file in Octave in which the file name is the same as the function which defines one function, but I would like to define multiple functions in one file. Is there any way to do this, or do I need a separate file for each function.
In this answer I will assume that your main objective is a tidy workspace rather than explicitly a one-file requirement.
Let's get the one-file approach out of the way. You can create a script m-file (not a function m-file), and define a number of command-line functions there. The octave manual has a section on this. Here's an example:
% in file loadfunctionDefinitions.m
1; % statement with side-effect, to mark this file as a script. See docs.
function Out = Return1(); Out = 1; end
function Out = Return2(); Out = 2; end
% ... etc
% in your main octave session / main script:
X = Return1() + Return2();
However, this is generally not recommended. Especially if you would require matlab compatible code, since matlab introduced 'script-local functions' much later than octave, and decided to do it in a manner incompatible to the existing octave implementation: matlab expects script-local functions to be defined at the end of the script; octave expects them to be defined before first use. However, if you use normal function files, everything is fine.
While I appreciate the "I don't like a folder full of functions" sentiment, the one-function-per-file approach actually has a lot of benefits (especially if you program from the terminal, which makes a wealth of tools twice as useful). E.g. you can easily use grep to find which functions make use of a particular variable. Or compare changes in individual functions from different commits, etc.
Typically the problem is more one of having such function files littering the directory, when other important files are present, e.g. data etc, and having so many files in one place makes finding what you want hard to spot, and feels untidy. But rather than have a single file with command-line definitions, there are a number of other approaches you can take, which are probably also better from a programmatic point of view, e.g.:
Simply create a 'helper functions' folder, and add it to your path.
Use subfunctions in your main functions whenever this is appropriate, to minimize the number of unnecessary files
Use a private functions folder
Use a 'package directory', i.e. a folder starting with the character '+', which creates a namespace for the functions contained inside. E.g. ~/+MyFunctions/myfun.m would be accessed from ~/ via MyFunctions.myfun(), without having to add +MyFunctions to the path (in fact you're not supposed to).
Create a proper class directory, and make your functions methods of that class
The last option may also achieve a one-file solution, if you use a newer-style classdef based class, which allows you to define methods in the same file as the class definition. Note however that octave-support for classdef-defined classes is still somewhat limited.
From the manual of dlopen, I see
" Instead, libraries should export routines using the attribute((constructor)) and attribute((destructor)) function attributes.
See the gcc info pages for information on these. Constructor routines are executed before dlopen() returns, and destructor routines are
executed before dlclose() returns.
"
I do not want the constructor in a specific shared library to run automatically, while the ones in other shared libraries are not affected. Is there any way to achieve that?
Actually, I'm using dlopen, dlsym, dladdr to find the exact path of some shared library.
I do not want the constructor in a specific shared library to run automatically
Too bad: the library author decided that his library can't be used safely unless the constructors are run, and he has more say than you do.
Actually, I'm using dlopen, dlsym, dladdr to find the exact path of some shared library.
Are you saying that the only reason you dlopen that library is just so that you can find the absolute path to it?
If so, why do you care about the absolute path in the first place?
I tried to build a shared library using wx and STL, and failed in an error of "multiple definition of". Please refer to:
https://code.google.com/p/gppanel/issues/detail?id=7
The declaration of wxPointListNode is not found in the sources. The suspicious lines are like these:
include/mathplot.h:85:WX_DECLARE_LIST(wxPoint, PointList);
include/mathplot.h:87:WX_DEFINE_LIST(PointList);
include/gpLineLayer.h:16:typedef std::deque<mpPointLayer*> mpPointList_t;
What the problem is?
Without the actual code this is just a guess, but I suspect that
include/mathplot.h:87:WX_DEFINE_LIST(PointList);
generates the full definition of PointList, including a non-templated method wxPointListNode::DeleteData. mathplot.h is included by all of the .cpp files (gpPanel.cpp, gpSeries.cpp, and baseData.cpp). Each cpp file is compiled into a .o file, so each has its own definition of DeleteData, and when you try to link the .o files together into lib/libgpPanel.so the linker issues the errors you're reporting.
The definition of the method needs to be in its own cpp file that's compiled and linked in.
All wxWidgets methods with DEFINE in their name expand into a definition of something and a definition can only be used once in a module, so it typically can't appear in a header file (unless you can guarantee that it's included by only a single source file). So just don't put it there.
Moreover, if this is your code, you should avoid using the legacy WX_DECLARE_LIST macro at all and just use std::list<> or std::vector<> instead. Or, if you really want to use only wx (which can only be important if you are targeting some embedded platform without good STL implementation), then use wxVector<>.
Anyone have any experience of using Closure js lib and Mootools in the same page?
Conflicts or works ok?
According to google:
The names of all Closure Library
functions and properties begin with a
dot-delimited path that prevents them
from accidentally overlapping with
names defined in non-Closure Library
code. This path is called a namespace.
(http://code.google.com/closure/library/docs/introduction.html)
So there should be no conflicts, also I checked the API documentation and it reaffirms my findings, for example, for array manipulation you have to go through the google namespace (goog):
goog.array.binaryInsert(array, value, opt_compareFn) ⇒
boolean
(http://closure-library.googlecode.com/svn/trunk/closure/goog/docs/closure_goog_array_array.js.html)
This is unlike the MooTools extention of the Array class itself.
Cheers,
Roman