LV Find Circular Edge 2 library function?

Hi,
I have been using the IMAQ Find Circular Edge vi to determine pixel information about images being generated in my lab. The program works fine, but upon looking into the vi, I couldn't seem to find the function or algorithm actually used to determine the edge. It lists it as LV_FindCircularEdge2, and the library call node lists the function inputs and the call itself, but not the contents of the function, and searching through the help library or online isn't turning this information up. Can anyone tell me the function? I am not interested in altering it, just would like to know exactly how it is done for the sake of understanding it.
Thanks in advance.

Hi,
Unfortunately, how the actual function is operating in the dll call is proprietary and as such, there isn't going to be documentation available to the public for how the function is working. Sorry I couldn't provide you with more information, but glad to hear that you have your application is working!
Cole R.
National Instruments
Applications Engineer

Similar Messages

What exactly is the roundness figure generated by IMAQ Find Circular Edge?

Is it a measure of pixels from the minimum to maximum diameter span of the data points (aka circularity). What numerical figure would a perfect circle return?
~~~~~~~~~~~~~~~~~~~~~~~~~~
"It’s the questions that drive us.”
~~~~~~~~~~~~~~~~~~~~~~~~~~

Hello,
Roundness or residual represents the least square error of the fitted circle to the entire set of points.
The value you would receive if you had a perfect circle would be 0 since there would be no error. You can see the formula for this value if you look at the online help for the IMAQ Fit Cirlce under residual. This is the function that is called by IMAQ Find Circular Edge.
Regards,
Andy Bell
Applications Engineer
National Instruments

Advantages of Find Circular Edge 3 over previous versions?

This particular IMAQ vision tool seems to have gone through a number of iterations. Can anyone comment on whether it actually does a better job of finding edges?

Hi another_novice,
I am not aware of the actually performance difference but you can compare their functionality with the documents below. The most noticeable difference is Find Circular Edge 3 has many more image input types than the other two, so now you can incorporate color.
IMAQ Find Circular Edge 3 VI
http://zone.ni.com/reference/en-XX/help/370281P-01/imaqvision/imaq_find_circular_edge_3/
IMAQ Find Circular Edge 2 VI
http://zone.ni.com/reference/en-XX/help/370281M-01/imaqvision/imaq_find_circular_edge_2/
IMAQ Find Circular Edge VI
http://zone.ni.com/reference/en-XX/help/370281L-01/imaqvision/imaq_find_circular_edge/
Tim O
Applications Engineer
National Instruments

Advantages of Solaris 10 library function calls over Solaris 8 calls.

Hi,
We are planning for a migration of OS from Solaris 8 to Solaris 10. We referred some documents related to Solaris 10 features and the 'What's new' document for Solaris 10. However we couldn't find much difference on library function calls.
It would be really grateful if anybody could give some more information on the function calls that are changed from Solaris 8.
Thanks,
Palani_techm.

Can you be more specific? There's are whole slew of changes (dtrace, driver framework changes (usb, gldv3, sata...), graphical changes (gnome, opengl) ), some function additions to make linux source compatibility easier. I don't think the C library (3C) has been changed that much minus new functions, since it would make forward compatibility more difficult.

Glibc 2.19 & find: sanity check of the fnmatch() library function fail

Since yesterdays update to glibc 2.19, find doesn't like searches by name. The update threw a hole lot of segmentations faults
[2014-02-12 15:06] [PACMAN] Running 'pacman --color auto -Sy'
[2014-02-12 15:06] [PACMAN] synchronizing package lists
[2014-02-12 15:07] [PACMAN] Running 'pacman --color auto -S -u'
[2014-02-12 15:07] [PACMAN] starting full system upgrade
[2014-02-12 15:08] [PACMAN] upgraded apr-util (1.5.3-1 -> 1.5.3-2)
[2014-02-12 15:08] [PACMAN] upgraded linux-api-headers (3.12.4-1 -> 3.13.2-1)
[2014-02-12 15:08] [ALPM] warning: /etc/locale.gen installed as /etc/locale.gen.pacnew
[2014-02-12 15:08] [ALPM-SCRIPTLET] Generating locales...
[2014-02-12 15:08] [ALPM-SCRIPTLET] de_DE.UTF-8
[2014-02-12 15:08] [ALPM-SCRIPTLET] en_US.UTF-8
[2014-02-12 15:08] [ALPM-SCRIPTLET] Generation complete.
[2014-02-12 15:08] [PACMAN] upgraded glibc (2.18-12 -> 2.19-1)
[2014-02-12 15:08] [PACMAN] upgraded binutils (2.24-1 -> 2.24-2)
[2014-02-12 15:08] [PACMAN] upgraded gcc-libs (4.8.2-7 -> 4.8.2-8)
[2014-02-12 15:08] [PACMAN] upgraded elfutils (0.157-1 -> 0.158-1)
[2014-02-12 15:08] [PACMAN] upgraded gcc (4.8.2-7 -> 4.8.2-8)
[2014-02-12 15:08] [PACMAN] upgraded shared-mime-info (1.2-1 -> 1.2-2)
[2014-02-12 15:08] [ALPM-SCRIPTLET] /tmp/alpm_Zt9oRn/.INSTALL: line 1: 10554 Segmentation fault (core dumped) xdg-icon-resource forceupdate --theme hicolor &>/dev/null
[2014-02-12 15:08] [PACMAN] upgraded kdelibs (4.12.1-1 -> 4.12.2-1)
[2014-02-12 15:08] [PACMAN] upgraded kdegraphics-mobipocket (4.12.1-1 -> 4.12.2-1)
[2014-02-12 15:08] [PACMAN] upgraded nepomuk-core (4.12.1-2 -> 4.12.2-1)
[2014-02-12 15:08] [PACMAN] upgraded kactivities (4.12.1-1 -> 4.12.2-1)
[2014-02-12 15:08] [PACMAN] upgraded kde-base-artwork (4.12.1-1 -> 4.12.2-1)
[2014-02-12 15:08] [PACMAN] upgraded oxygen-icons (4.12.1-1 -> 4.12.2-1)
[2014-02-12 15:08] [ALPM-SCRIPTLET] /tmp/alpm_lNExqJ/.INSTALL: line 1: 10562 Segmentation fault (core dumped) xdg-icon-resource forceupdate --theme hicolor &>/dev/null
[2014-02-12 15:08] [PACMAN] upgraded kdebase-runtime (4.12.1-3 -> 4.12.2-1)
[2014-02-12 15:08] [PACMAN] upgraded kdebase-lib (4.12.1-1 -> 4.12.2-1)
[2014-02-12 15:08] [PACMAN] upgraded nepomuk-widgets (4.12.1-1 -> 4.12.2-1)
[2014-02-12 15:08] [PACMAN] upgraded kdebase-dolphin (4.12.1-1 -> 4.12.2-1)
[2014-02-12 15:08] [PACMAN] upgraded kdebase-konsole (4.12.1-1 -> 4.12.2-1)
[2014-02-12 15:08] [PACMAN] upgraded kdebase-plasma (4.12.1-1 -> 4.12.2-1)
[2014-02-12 15:08] [ALPM-SCRIPTLET] /tmp/alpm_jc0NOD/.INSTALL: line 1: 10571 Segmentation fault (core dumped) xdg-icon-resource forceupdate --theme hicolor &>/dev/null
[2014-02-12 15:08] [PACMAN] upgraded kdepim-runtime (4.12.1-1 -> 4.12.2-1)
[2014-02-12 15:08] [ALPM] warning: /usr/share/config/kdm/kdmrc installed as /usr/share/config/kdm/kdmrc.pacnew
[2014-02-12 15:08] [ALPM-SCRIPTLET] /tmp/alpm_9emqkf/.INSTALL: line 10: 10582 Segmentation fault (core dumped) xdg-icon-resource forceupdate --theme hicolor &>/dev/null
[2014-02-12 15:08] [PACMAN] upgraded kdebase-workspace (4.11.6-1 -> 4.11.6-2)
[2014-02-12 15:08] [ALPM-SCRIPTLET] /tmp/alpm_HVYliW/.INSTALL: line 1: 10587 Segmentation fault (core dumped) xdg-icon-resource forceupdate --theme hicolor &>/dev/null
[2014-02-12 15:08] [PACMAN] upgraded libkipi (4.12.1-1 -> 4.12.2-1)
[2014-02-12 15:08] [ALPM-SCRIPTLET] /tmp/alpm_JMyH2D/.INSTALL: line 1: 10591 Segmentation fault (core dumped) xdg-icon-resource forceupdate --theme hicolor &>/dev/null
[2014-02-12 15:08] [PACMAN] upgraded kdegraphics-gwenview (4.12.1-2 -> 4.12.2-1)
[2014-02-12 15:08] [ALPM-SCRIPTLET] /tmp/alpm_BOmkIm/.INSTALL: line 1: 10595 Segmentation fault (core dumped) xdg-icon-resource forceupdate --theme hicolor &>/dev/null
[2014-02-12 15:08] [PACMAN] upgraded kdegraphics-kcolorchooser (4.12.1-1 -> 4.12.2-1)
[2014-02-12 15:08] [ALPM-SCRIPTLET] /tmp/alpm_V9lYA5/.INSTALL: line 1: 10598 Segmentation fault (core dumped) xdg-icon-resource forceupdate --theme hicolor &>/dev/null
[2014-02-12 15:08] [PACMAN] upgraded kdegraphics-ksnapshot (4.12.1-1 -> 4.12.2-1)
[2014-02-12 15:08] [PACMAN] upgraded libkexiv2 (4.12.1-2 -> 4.12.2-1)
[2014-02-12 15:08] [ALPM-SCRIPTLET] /tmp/alpm_NKbRqP/.INSTALL: line 1: 10602 Segmentation fault (core dumped) xdg-icon-resource forceupdate --theme hicolor &>/dev/null
[2014-02-12 15:08] [PACMAN] upgraded kdegraphics-okular (4.12.1-1 -> 4.12.2-1)
[2014-02-12 15:08] [ALPM-SCRIPTLET] /tmp/alpm_1CccYz/.INSTALL: line 1: 10606 Segmentation fault (core dumped) xdg-icon-resource forceupdate --theme hicolor &>/dev/null
[2014-02-12 15:08] [PACMAN] upgraded libkdcraw (4.12.1-2 -> 4.12.2-1)
[2014-02-12 15:08] [PACMAN] upgraded kdegraphics-thumbnailers (4.12.1-1 -> 4.12.2-1)
[2014-02-12 15:08] [PACMAN] upgraded kdemultimedia-ffmpegthumbs (4.12.1-1 -> 4.12.2-1)
[2014-02-12 15:08] [ALPM-SCRIPTLET] /tmp/alpm_PRYdSk/.INSTALL: line 1: 10609 Segmentation fault (core dumped) xdg-icon-resource forceupdate --theme hicolor &>/dev/null
[2014-02-12 15:08] [PACMAN] upgraded kdemultimedia-kmix (4.12.1-1 -> 4.12.2-1)
[2014-02-12 15:08] [PACMAN] upgraded kdemultimedia-mplayerthumbs (4.12.1-1 -> 4.12.2-1)
[2014-02-12 15:08] [PACMAN] upgraded kdepimlibs (4.12.1-1 -> 4.12.2-1)
[2014-02-12 15:08] [PACMAN] upgraded kdeutils-ark (4.12.1-1 -> 4.12.2-1)
[2014-02-12 15:08] [PACMAN] upgraded lib32-elfutils (0.157-1 -> 0.158-1)
[2014-02-12 15:08] [PACMAN] upgraded lib32-glibc (2.18-12 -> 2.19-1)
[2014-02-12 15:08] [PACMAN] upgraded lib32-gcc-libs (4.8.2-7 -> 4.8.2-8)
[2014-02-12 15:08] [PACMAN] upgraded libsasl (2.1.26-6 -> 2.1.26-7)
[2014-02-12 15:08] [PACMAN] upgraded mpd (0.18.7-1 -> 0.18.8-1)
[2014-02-12 15:08] [PACMAN] upgraded nginx (1.4.4-2 -> 1.4.5-1)
[2014-02-12 15:08] [PACMAN] upgraded openjpeg (1.5.1-1 -> 1.5.1-2)
[2014-02-12 15:08] [PACMAN] upgraded pam (1.1.8-2 -> 1.1.8-3)
[2014-02-12 15:08] [PACMAN] upgraded python2-numpy (1.8.0-1 -> 1.8.0-2)
[2014-02-12 15:08] [PACMAN] upgraded redland (1:1.0.17-1 -> 1:1.0.17-2)
[2014-02-12 15:08] [PACMAN] upgraded s-nail (14.5.2-3 -> 14.5.2-4)
[2014-02-12 15:08] [PACMAN] upgraded sudo (1.8.9.p4-1 -> 1.8.9.p5-1)
[2014-02-12 15:08] [PACMAN] upgraded systemd (208-10 -> 208-11)
[2014-02-12 15:08] [PACMAN] upgraded systemd-sysvcompat (208-10 -> 208-11)
[2014-02-12 15:08] [ALPM-SCRIPTLET] /tmp/alpm_7YRIvT/.INSTALL: line 10: 10659 Segmentation fault (core dumped) mkfontdir usr/share/fonts/local
[2014-02-12 15:08] [PACMAN] upgraded terminus-font (4.38-3 -> 4.38-4)
[2014-02-12 15:08] [PACMAN] upgraded vim-systemd (20130410-1 -> 20140209-1)
[2014-02-12 15:08] [PACMAN] upgraded whois (5.1.0-1 -> 5.1.1-1)
[2014-02-12 15:08] [PACMAN] upgraded xdg-utils (1.1.0.git20140109-1 -> 1.1.0.git20140207-1)
[2014-02-12 15:08] [PACMAN] upgraded xf86-video-intel (2.99.909-2 -> 2.99.910-1)
After that nearly all applications segfaulted but somehow it everything works again. Except for find (which I only recognized after mkinitcpio destroyed my initramfs......):
# find -name \*.pkg.tar.xz
find: sanity check of the fnmatch() library function failed.
Regex, type and all other operators work as expected:
# find -regex '.*\.pkg\.tar\.xz'
./gcc-4.8.2-7-x86_64.pkg.tar.xz
./binutils-2.24-1-x86_64.pkg.tar.xz
./glibc-2.18-12-x86_64.pkg.tar.xz
./gcc-libs-4.8.2-7-x86_64.pkg.tar.xz
# find -type d
# pacman -Q findutils glibc
findutils 4.4.2-5
glibc 2.19-1
First is suspected it to be a locale issue, but everything seems to be fine:
# diff -u0 {,/}etc/locale.gen
--- etc/locale.gen 2014-02-07 23:56:45.000000000 +0100
+++ /etc/locale.gen 2014-02-12 19:43:03.037279970 +0100
@@ -124 +124 @@
-#de_DE.UTF-8 UTF-8
+de_DE.UTF-8 UTF-8
@@ -161 +161 @@
-#en_US.UTF-8 UTF-8
+en_US.UTF-8 UTF-8
# locale-gen
Generating locales...
de_DE.UTF-8
en_US.UTF-8
Generation complete.
Downgrading to glibc 2.18-12 solved the problem for now...
# pacman -U --noprogressbar --noconfirm *
loading packages...
warning: downgrading package binutils (2.24-2 => 2.24-1)
warning: downgrading package gcc (4.8.2-8 => 4.8.2-7)
warning: downgrading package gcc-libs (4.8.2-8 => 4.8.2-7)
warning: downgrading package glibc (2.19-1 => 2.18-12)
resolving dependencies...
looking for inter-conflicts...
Packages (4): binutils-2.24-1 gcc-4.8.2-7 gcc-libs-4.8.2-7 glibc-2.18-12
Total Installed Size: 134.89 MiB
Net Upgrade Size: -0.42 MiB
:: Proceed with installation? [Y/n]
checking keyring...
checking package integrity...
loading package files...
checking for file conflicts...
checking available disk space...
downgrading glibc...
warning: /etc/locale.gen installed as /etc/locale.gen.pacnew
downgrading binutils...
downgrading gcc-libs...
downgrading gcc...
# find -name \*.pkg.tar.xz
./gcc-4.8.2-7-x86_64.pkg.tar.xz
./binutils-2.24-1-x86_64.pkg.tar.xz
./glibc-2.18-12-x86_64.pkg.tar.xz
./gcc-libs-4.8.2-7-x86_64.pkg.tar.xz
According to the findutils manual one should file a bug report for this message, but I don't think they expect glibc to be the buggy implementation of fnmatch that looks enough like the GNU version to fool configure, but which doesn't work properly.
Does anybody experience similar problems? Does anybody have suggestions how to solve this?
Last edited by auti (2014-02-13 22:14:12)

I've regenerated the locales multiple times but only the upgrade to findutils 4.5.12 worked.
glibc 2.19-2 works with the current findutils.
But if a corrupt locale archive file caused this, why didn't findutils 4.5.12 complained about this?
Anyhow: It works, I'm happy; thanks for your effort, Allan!

How to call a C pointer from call library function node

I have a client/server application which the client I am trying to develop using Labview. When I use to communicate the server and the client using the program provided by the manufacter, the system works perfectly.
Now, I am trying to develop a system using labview, because I need to get another things.
I have the DLL provided by the manufacter and the .h too, so I can check the functions parameters. One of these functions needs to be called using a struct element. Probably, the function's DLL instantiates the elements of this struct. I use the call library function node to do it.
When I receive the data, the function returns to me the struct that I passed as a parameter before, and then I can read all the elements of the struct, except the string element that returns nothing. The struct elements that are numerical, I can read them perfectly.
Another thing that is important to say, is that the string data was not returned in fact by the DLL function that the system calls. I have to pass a pointer (I use it as unsigned 16 in Labview, but I tried before as string and unsigned 8) as a parameter, and this pointer will point to the memory location that the string is. When I try to read what is returned by the function, I can read nothing. The same function returns that the size of data that is returning is 17 bytes.
How can I solve it?
Thank you in advance

Did you take a look at the example that ships with LabVIEW that shows how to do all sorts of data passing to DLLs. I believe your situation is one of the examples listed. You can find the example VI in the "<LabVIEW install directory>\examples\dll\data passing" directory.

Window doesn't close wheh Call Library Function Node set to Run in Any Thread

This is a problem regarding Call Library Function Nodes running in the UI thread or any thread.
I have a camera which has its own API supplied as a dll. I have created a set of VI wrappers which each call a function in the dll through a Call Library Function Node.
Initially each CLFN was set to 'Run in the UI thread' (the default).
To start the camera streaming images I call (through a CLFN)
ICubeSDK_Start(int CamIndex, Hwnd, ImgHandle, bool Preview, bool callback);
If Preview = True then the image is displayed in a preview window.
If ImgHandle = NULL a default preview window
is used.
In the CLFN definition I define:
ImgHandle as a U32
Preview as a I32
To stop the camera streaming images I call
ICubeSDK_Stop(int CamIndex)
In the actual implementation I set ImgHandle = 0 (NULL) and Preview = 1 (true).
This all works fine, and a preview window is opened and images displayed. When I call ICubeSDK_Stop the preview window is closed.
However, I would prefer to set the CLFN to 'Run in any thread' because
a) when run in the UI thread the preview window randomly gets sent to the back when I switch focus between open VI windows (presumably because it is in the same thread as the VIs)
b) I don't want to put unnecessary stuff in the UI thread
c) my (naive?) understanding is that it is safer to run in any thread
So I have set all CLFNs to 'Run in any thread'
When I do this the preview window opens OK, and behaves like any other non LabVIEW controlled window in terms of focus. But when I call ICubeSDK_Stop() the preview window does not get closed properly, it just shows a blank image. I can't close it manually, there is no X in the corner and no option to close it from the taskbar. To get rid of it I have to close the LabVIEW project it is spawned from, which often results in a crash. It does appear as a separate item in task manager but if I 'end process' it, LabVIEW closes (and often crashes) as well.
If I change only the CLFNs that call the Start and Stop functions back to 'Run in the UI thread' then it all works fine again, except that the preview window gets sent to the back randomly as before.
So, what do I have to do to get the preview window to close properly if I set the CLFN to 'Run in any thread'.
Alternatively, is there a way to close the window programmatically (ie force it to close) after I have called ICube_Stop.
Thanks
DAve

Hi Dave,
The "Run In UI Thread" switches from the thread the VIs currently executing in to the user interface thread. If you select "Run in Any Thread", the Call Library Function Node continues in the currently executing thread. By default, all Call Library Function Nodes run in the User Interface thread.
Before you configure the Call Library Function Node to run in any thread, you have to make sure that the code is thread safe. Code is thread safe when it does not store any global data (e.g. global variables, files on disks, etc.), does not access any hardware, does not make calls to any functions, libraries or drivers that are not thread safe.
Unfortunately, since you said that your DLL accesses hardware, it is not recommended to use "Run in Any Thread." This is probably why you are seeing the crash.
If your preview window gets sent to the back you can programmatically bring it forward. Here is an example of how this can be done: http://decibel.ni.com/content/docs/DOC-4551
If you want to completely close the window down you can do so as described in this link: http://digital.ni.com/public.nsf/allkb/81E9C1441900FFCE8625748F0055DBB0?OpenDocument
I also thought you might find this useful: http://zone.ni.com/devzone/cda/tut/p/id/3009
I hope this helps.
Regards,
Mahdieh G
Applications Engineer
National Instruments UK&Ireland

How do you use the windows User32.dll Library functions to read variables from other applications that are running

I am trying to read a text box from a programme running at the same time as my Labview application using calls to the Windows
User32.dll. I believe I need to find the window handle for the 'form' containing this text string and use this together with
various other defined input variables to access the sting.
I have no experience of using this 'Call Library Function Node', but have an understanding of the 'C' programming language. Does anyone have
example Labview code showing how this might be done.
Thanks

If you're trying to access information that's being displayed in the window of another application and that application has no ActiveX interface, then yes, Windows calls can be used. There's a very good example on calling DLLs that ship with LabVIEW. Open the Example Finder (Help->Find Examples) and switch to the Search tab. Enter "Call" in the search box and open the VI "Call DLL". Run the VI, select any of the examples, and click the "Open Example VI..." button. That shows you how to call a DLL.
Now, given that you have no experience in calling DLLs, have only an "understanding" of C (which to me means you have never written something like a DLL), and don't seem to know that much about what Windows functions you may need, you're going to find this route pretty difficult, especially since you have to deal with Windows API calls, which are not always that easy to do from LabVIEW.
Let me propose an alternate solution. Go over to http://www.autoitscript.com/autoit3/ and download AutoIt. This is an automation tool that allows you to automate just about anything you want. It has an ActiveX interface that you can call from LabVIEW. I've attached an example VI that shows you how to use it to get the value of a text box from one of the tabs in the computer "System Properties" control panel applet.
Attachments:
AutoIt Example (v7).vi ‏25 KB

How can I debug the Call Library Function at run-time

I've written a VI using the CLF to call a DLL which was compiled off-site by another engineer using MSVC. Even though the VI runs without flagging any errors, the VI is not doing what I expect. Is there any way of finding out if the DLL is been called correctly? The first function that is called doesn't return any value, but I think that it should. Does this mean that the DLL is not being called correctly? Note also that the DLL works fine with a JAVA GUI.

Make sure that you are specifying the proper function prototype in the call library function. If you are slightly off the call will not work properly. Ask the offsite engineer to provide you with this data. Another tip is to build the dll with the option to show front panel when called. You can actually popup the dll like you would a subvi. If you design it with test indicators showing on the front panel that is a great way to determine if it is working. Hope this helps.
BJD1613
Lead Test Tools Development Engineer
Philips Respironics
Certified LV Architect / Instructor

LV 8.6 library function in an example is not found

Several "examples" in LV 8.6 include a particular library function that is not found when I load the example VI. Where can I find this function? I have an "example" of one of the vi's attached containing the mystery function.
Thank you,
Chuck
Solved!
Go to Solution.
Attachments:
Error Handling callingVI.vi ‏20 KB

Additional info: The Information text box on the Example Finder provides descriptions for the examples. If an example requires a toolkit and you don't have it installed, it will tell you.
Attachments:
toolkit missing.png ‏3 KB

How to find out which C library I am using?

On my Solaris 9 UltraSparc system,
% echo $LD_LIBRARY_PATH
/opt/gcc/3.4.4/lib:/opt/glib/2.12.1/lib:/opt/gnome/lib:/opt/openssl/0.9.7g/lib
% /usr/lib/libc.so
usage: ld.so.1 [-e option,...] dynamic-object [object args,...]
On my Solaris 10 x86 system,
% echo $LD_LIBRARY_PATH
/pkg/gcc/4.2.1/lib:/opt/gcc/current/lib:/opt/glib/2.10.1/lib:/usr/sfw/lib:/usr/lib/mps:/opt/openldap/lib:/opt/openssl/current/lib
% /usr/lib/libc.so
usage: ld.so.1 [-e option,...] dynamic-object [object args,...]
On my Linux/x86 system,
% echo $LD_LIBRARY_PATH
/opt/openssl/0.9.7g/lib:/opt/gcc/3.4.4/lib:/opt/binutils2.13/lib:/opt/glib/2.12.1/lib:/opt/java/j2sdk1.4.1_01/lib
% /lib/libc.so.6
GNU C Library stable release version 2.6.1, by Roland McGrath et al.
From the above, can one tell what C library I am linking to on the Solaris systems? If not, how can one tell? How do I know the exact location of the C library I am using?
On the Linux/x86 system, I can use gnu_get_libc_version() to find out the version of glibc I am supposedly using. But it does not work when I compiled the identical C program using gcc on the Solaris 9/UltraSparc and Solaris 10/x86 systems. If I can use gnu_get_libc_version() , does that mean for sure that my C program links to glibc? On the other hand, if the linker reports that gnu_get_libc_version() is not found, does that mean for sure that my C program is not linked to glibc?
Is there a function on the Sun libc similiar to gnu_get_libc_version()?
http://docs.sun.com/source/819-3690/Using.Libs.html says "The Solaris operating system comes with several libraries installed in /usr/lib. Most of these libraries have a C interface. Of these, the libc and libm, libraries are linked by the CC driver by default." If one wants to link to the glibc library, how to override the default? How to find out the default? Is it in some environ variable? If one changes the CC driver to gcc, does the default remain the Sun libc? And if one compiles explictly using gcc, i.e. "gcc myprog.c", is the default C library the Sun Library, or glibc?
gnu.org has a (web page for the) glibc manual but I am not able to find a Sun C Library Manual. Is there one?
Edited by: hzmonte on Jun 28, 2008 1:43 AM

I'll discuss only the Sun C compiler here. For questions about gcc, look in the gcc manual, or try a gcc forum.
Run the command "ldd" on an executable file or shared library, and it will report the shared libraries that it will link to, based on any runpath in the file, and on LD_LIBRARY_PATH. Example: % echo $LD_LIBRARY_PATH
LD_LIBRARY_PATH: Undefined variable
% cc hello.c
% ldd a.out
        libc.so.1 =>     /lib/libc.so.1
        libm.so.2 =>     /lib/libm.so.2
        /platform/SUNW,A70/lib/libc_psr.so.1 BTW, except possibly for testing, there is usually no need to set LD_LIBRARY_PATH, and setting it is usually a bad idea. For more on this topic see Rod Evans' blog:
[http://blogs.sun.com/rie/entry/tt_ld_library_path_tt]
Prefer to set a runpath in the executable so that no client needs to set LD_LIBRARY_PATH.
If you want to know what libraries the C compiler will link, based on a given command line, you can add the -v (verbose) option, which will display each subcommand. Or you can use the -### option, which shows what commands would be run. Example: % cc -### hello.c
### Note: NLSPATH = \
/opt/SUNWspro/prod/bin/../lib/locale/%L/LC_MESSAGES/%N.cat:/opt/SUNWspro/prod/bin/../../lib/locale/%L/LC_MESSAGES/%N.cat
###     command line files and options (expanded):
### hello.c
/opt/SUNWspro/prod/bin/acomp -xldscope=global -i hello.c -y-fbe -y/opt/SUNWspro/prod/bin/fbe -y-xarch=generic \
-y-xmemalign=8i -y-o -yhello.o -y-verbose -y-xthreadvar=no%dynamic -y-comdat -xdbggen=no%stabs+dwarf2+usedonly \
-xdbggen=incl -y-s -m32 -fparam_ir -Qy -D__SunOS_5_10 -D__SUNPRO_C=0x590 -D__SVR4 -D__sun -D__SunOS -D__unix \
-D__sparc -D__BUILTIN_VA_ARG_INCR -D__C99FEATURES__ -Xa -D__PRAGMA_REDEFINE_EXTNAME -Dunix -Dsun \
-Dsparc -D__RESTRICT -xc99=%all,no%lib -D__FLT_EVAL_METHOD__=0 -I/opt/SUNWspro/prod/include/cc \
"-g/opt/SUNWspro/prod/bin/cc -c " -fsimple=0 -D__SUN_PREFETCH -destination_ir=yabe
### Note: LD_LIBRARY_PATH = <null>
### Note: LD_RUN_PATH = <null>
/usr/ccs/bin/ld /opt/SUNWspro/prod/lib/crti.o /opt/SUNWspro/prod/lib/crt1.o /opt/SUNWspro/prod/lib/misalign.o \
/opt/SUNWspro/prod/lib/values-xa.o hello.o -Y "P,/opt/SUNWspro/prod/lib/sparc:/opt/SUNWspro/prod/lib:/usr/ccs/lib:/lib:/usr/lib" \
-Qy -lc /opt/SUNWspro/prod/lib/crtn.oThe basic runtime support library is /lib/libc.so.1, on any version of Solaris, used by every compiler version. You can check the patch version of the library by running
showrev -p | grep <patch>
where <patch> is the patch number for the library. The patch number depends on the Solaris version. You can get more information at [http://sunsolve.sun.com].
There is no manual specifically for the C library. There is a Solaris man page for each function in the library, and you can check the C Users Guide and the Solaris Linker and Libraries Guide for additional information.

How to find out what are the functions supported by string class

Hi,
Can any one let me know how to find what are all the functions supported by the string class in standard(STL) library on solaris.
Regards,
Vignesh

1. Any C++ textbook that covers the Standard Library will tell you about the standard string class. A good tutorial and reference for the entire Standard Library is "The C++ Standard Library" by Nicolai Josuttis, published by Addison Wesley.
2. WIth Sun C++, the command
man -s3C++ basic_string
provides documentation for the default libCstd version of the Standard Library.
3. You could look at the <string> header itself. I don't recommend that approach.

How to add a link to an interactive svg using edge commons library

Hi,
I've been playing around with this wonderful Edge Commons interactive SVG tutorial
My question is : How to add an external link "url" to an interactive svg using edge commons library ?
Edge commons example file :
http://edgedocks.com/market/interactive-svg-example-project-edge-commons
Edge commons video tutorial :
http://www.youtube.com/watch?v=4UEB6gaLKuw
I have adapted this tutorial to an interactive map, http://madudesign.com/works/france/ every thing is going fine until I couldn't figure out to link a particular url on each part of the region of the map.
I managed to figure out how to change colors on the different parts of the map on mouse over and mouse out but I'm not quite comfortable with JavaScript since I don't use it every day...
I have tryed to link to an url by passing it on the illustrator layer and via the onclick event (event.target.id) to a simple url
http://redpen.io/6svh5u
then working in Edge and publishing on the browser the link returns me a weird url line by replacing the original url slashes "//" by "_x2F_" and I must have misunderstood the proper JavaScript line to open that link from there...
for example on my actual exemple "http://madudesign.com/works/france/"
the first top region of France is normally a link to "http://www.google.com" and it returns "http:_x2F__x2F_www.google.com" plus the complete path to the file too...
I don't know how to get around this trick and have back for each region a particular clean link from the event target id of the svg...
thank-you for any help
matt
link to my edge animate file if needed :
http://madudesign.com/works/france/carte_de_france.zip

I got an answer from the Edge Commons dream team and I am very grateful to them :
"The problem that you bumped into was that you hadn't included a valid URL so far. We weren't sure if you wanted to include them within the SVG file or if you wanted to implement the functionality within Edge Animate. We came up with a solution for the latter one, with a simple switch in the js code:
You have to type in the appropriate URL of course for all the cases."
I have to share the final result:
http://www.madudesign.com/works/france/france_map/
And the zipped project file:
http://www.madudesign.com/works/france/france_map.zip
Thanks to Daniel & Simon
Matt

Problem with Call Library Function. Want to pass a string and return a string, but my compiler does not recognize "CStr" and Labview does not recognize my "char *function()" callout

Hi, I'm trying to use a .DLL I wrote in Visual C++ .NET. The Call Library Function generates a function prototype of "CStr Parser(CStr arg_raw)"
but my compiler won't accept this. So I change it to how C normally deals with strings "char *Parser(char *arg_raw). Now the Call Librafy Function does not find "Parser" in my .DLL though it is definitely there!
Help!
-Fong

Hello
You will need to include extcode.h in your C file. You can find this under ..\LabVIEW\cintools folder.
The include has all the defines you will need.
Bilal Durrani
NI
Bilal Durrani
NI

Call Library Function (DLL) Node Configuration

This issue was discussed few times on this forum (see for example http://forums.ni.com/ni/board/message?board.id=170&message.id=182911 ), but I still have a problem.
My question is - how to define the call to DLL without to specify its full path in order to be able to change the directory path without to change all calls to DLL functions within VI.
So, I did:
1. I put my DLL and my VI in the same directory.
2. I defined this directory in VI search path. This directory also defined as enviroment variable.
3. I use only one call to DLL in this specific VI (just as example in order to simplify the problem).
4. I define only DLL name without the path in CLF Node.
But, every time when I close CLF Node configution window, the program search for the DLL, find it and put full DLL path inside.
I will be very thankful if anyone can help me to overcome this problem.
Best regards,
Boris

Hello Boris,
To sum up the previous posts, when you specify the DLL when configuring the Call Library Function
node, internally LabVIEW stores in the VI either 1) the name of the
DLL, or 2) a relative path from the VI to the DLL (including the name
of the DLL). What's displayed in the dialog (in 'Library Name or Path'
field) is either 1) the name of the DLL, or 2) an absolute path that is
formed by appending the DLL's relative path to the VI's absolute path.
In
case 1, LabVIEW uses the Windows system search paths to load the DLL.
That is, it looks for the DLL in \windows\system32 folder, then if not
found there, it uses the folders specified in the PATH environment
variable, etc.
In case 2, LabVIEW tries to load the DLL from the
computed absolute path (VIs current path combined with the relative
path to the DLL that LabVIEW stored internally). And if not found
there, LabVIEW uses the VI Search Path (that can be set from Tools »
Options in the category of Paths).
So even though LabVIEW automatically puts an absolute path to the DLL
in the Call Library Function Node, as long as you will specify the
correct folder for the DLL in the VI Search Path, you should be Ok. However, if you want to
have a fixed location for the DLL, then it is best to keep it in the
\windows\system32 folder, and specify just the name of the DLL when
configuring the Load Library Function node (this way LabVIEW will not
automatically turn it into an absolute path).
Also, these knowledge base articles might be helpful:
Why Does My VI Prompt for My DLL Every Time I Open It?
LabVIEW Searching for a DLL Used in the Call Library Function Node
My Stand-Alone Executable Cannot Find My DLL, Even Though I Have Specified the Path for the DLL
Hope this helps and good luck with your application!
Shakhina P.
NIC

LV Find Circular Edge 2 library function?

Similar Messages

Maybe you are looking for