Lide Leads a Life
Friday, August 26, 2011
Wednesday, August 10, 2011
Thursday, June 9, 2011
Shared library cannot be found issue
This issue happens if the location of the shared library used when compiling your code is not the default search location of the OS. To solve this problem there are two easy ways:
A. Set environment variable $LD_RUN_PATH before compiling/linking the executables
The value of this environment variable should be the paths where your shared libraries are located, separated by colons if there are two or more directories. It will be used when compiling/linking so that the location information will be in the executable generated.
or
B. Set environment variable $LD_LIBRARY_PATH before running the executables
This environment variable is similar to $LD_RUN_PATH, except that you need it when you run your executables. It can be considered as an extended search paths for OS when running executables.
If you don't want to re-compile/re-link your code, method B is convenient. However, the drawback is that your need to have your correct paths in $LD_LIBRARY_PATH every time your run your executables (of course you can choose to code that into your starting scripts like '.bashrc' to make sure it happens). Whereas method A is more like a once for all solution, as long as your shared library paths don't change.
Afterthought: due to the important role $LD_RUN_PATH played in the linking process, we need to make sure it has the correct value when linking. In my experience $LD_RUN_PATH has higher search priority over $LD_LIBRARY_PATH. So if there is a library in $LD_RUN_PATH specified during linking that is not the version want to use, you have no way to correct that using $LD_LIBRARY_PATH during running, and the only choice is to re-link the program after correct the value of $LD_RUN_LIBRARY.
A. Set environment variable $LD_RUN_PATH before compiling/linking the executables
The value of this environment variable should be the paths where your shared libraries are located, separated by colons if there are two or more directories. It will be used when compiling/linking so that the location information will be in the executable generated.
or
B. Set environment variable $LD_LIBRARY_PATH before running the executables
This environment variable is similar to $LD_RUN_PATH, except that you need it when you run your executables. It can be considered as an extended search paths for OS when running executables.
If you don't want to re-compile/re-link your code, method B is convenient. However, the drawback is that your need to have your correct paths in $LD_LIBRARY_PATH every time your run your executables (of course you can choose to code that into your starting scripts like '.bashrc' to make sure it happens). Whereas method A is more like a once for all solution, as long as your shared library paths don't change.
Afterthought: due to the important role $LD_RUN_PATH played in the linking process, we need to make sure it has the correct value when linking. In my experience $LD_RUN_PATH has higher search priority over $LD_LIBRARY_PATH. So if there is a library in $LD_RUN_PATH specified during linking that is not the version want to use, you have no way to correct that using $LD_LIBRARY_PATH during running, and the only choice is to re-link the program after correct the value of $LD_RUN_LIBRARY.
Wednesday, April 13, 2011
Translate from MATLAB to IDL
I now need to use IDL more and MATLAB less, since IDL is the standard tool for my current job setting. Although I am more familiar with MATLAB, which I have been using exclusively for more than half a decade as a programing and visualization tool, I have to get used to IDL and its verbose programing style (as compared to MATLAB) for its advantage in the long run. Fortunately, the difference between IDL and MATLAB is not that big, and translating code from one to the other is a manageable task, provided one is reasonable familiar with both languages.
Now the other essential issue is transferring data between the two, so that I can freely change between the two languages once deemed needed. One major reason for this is the two software have some different visualization functions, thus one is often good for one purpose and the other is good for another.
To transfer data between the two, the data need to be saved as binary format.
1. from MATLAB to IDL:
The example is to transfer a 50x100x24 array 'zeta' in float (32bit) and a 24x1 double vector 'time' from MATLAB to IDL:
1) under matlab
>> whos
Name Size Bytes Class Attributes
zeta 50x100x24 960000 double
time 24x1 192 double
>> fid = fopen('data.bin', 'w');
>> fwrite(fid, zeta, 'float'); % note: although h is originally double in memory, specifying 'float' will result in float type in file
>> fwrite(fid, time, 'double');
>> fclose(fid);
We now have a binary file 'data.bin' that contains the data we want to transfer to IDL
2) under IDL
IDL> Z = FLTARR(50,100,24) ; note: it's important to get the type and dimension right
IDL> T = DBLARR(24)
IDL> OPENR, UNIT, 'data.bin', /GET_LUN
IDL> READU, UNIT, Z, T
IDL> CLOSE, UNIT
Now the data has been succesfully transferred to IDL as Z (=zeta) and T (=time)
2. From IDL to MATLAB:
The example is to transfer a [600, 800] UINT(16 bit in IDL) array from IDL to MATLAB (corresponding to 'ushort' type).
1) under IDL
IDL> help
% At $MAIN$
SCATTER UINT = Array[600, 800]
Compiled Procedures:
$MAIN$
Compiled Functions:
IDL> openw, unit, 'data.bin', /get_lun
IDL> writeu, unit, scatter
IDL> close, unit
2) under MATLAB
>> fid = fopen('data.bin', 'r');
>> sctr = fread(fid, [600 800], 'ushort');
>> fclose(fid)
Now the other essential issue is transferring data between the two, so that I can freely change between the two languages once deemed needed. One major reason for this is the two software have some different visualization functions, thus one is often good for one purpose and the other is good for another.
To transfer data between the two, the data need to be saved as binary format.
1. from MATLAB to IDL:
The example is to transfer a 50x100x24 array 'zeta' in float (32bit) and a 24x1 double vector 'time' from MATLAB to IDL:
1) under matlab
>> whos
Name Size Bytes Class Attributes
zeta 50x100x24 960000 double
time 24x1 192 double
>> fid = fopen('data.bin', 'w');
>> fwrite(fid, zeta, 'float'); % note: although h is originally double in memory, specifying 'float' will result in float type in file
>> fwrite(fid, time, 'double');
>> fclose(fid);
We now have a binary file 'data.bin' that contains the data we want to transfer to IDL
2) under IDL
IDL> Z = FLTARR(50,100,24) ; note: it's important to get the type and dimension right
IDL> T = DBLARR(24)
IDL> OPENR, UNIT, 'data.bin', /GET_LUN
IDL> READU, UNIT, Z, T
IDL> CLOSE, UNIT
Now the data has been succesfully transferred to IDL as Z (=zeta) and T (=time)
2. From IDL to MATLAB:
The example is to transfer a [600, 800] UINT(16 bit in IDL) array from IDL to MATLAB (corresponding to 'ushort' type).
1) under IDL
IDL> help
% At $MAIN$
SCATTER UINT = Array[600, 800]
Compiled Procedures:
$MAIN$
Compiled Functions:
IDL> openw, unit, 'data.bin', /get_lun
IDL> writeu, unit, scatter
IDL> close, unit
2) under MATLAB
>> fid = fopen('data.bin', 'r');
>> sctr = fread(fid, [600 800], 'ushort');
>> fclose(fid)
blog opened
A place to make some notes
A place to record some feelings
A place to share some experiene
A place to record some feelings
A place to share some experiene
Subscribe to:
Posts (Atom)