Shared libraries

[Yves Surrel]

Hello

I try to create a shared library (named MySharedLib ) with PowerMops
5.5, using

***********

:entry MyEntry { -- }
10 beep
;entry

************

and then to use it with:

************

library MySharedLib
libcall MyEntry { -- }
MyEntry

************

I get:

Error # 220 Couldn't load shared library - see value system_err# for
error

system_err# .
-2804

What is wrong? I have put MySharedLib in the same directory as
PowerMops (btw, what are the commands equivalent to chdir and dir in
PM?)

Labview does not find the entry MyEntry in MySharedLib either.

Thanks for any help. May I have a working example?


Yves

[Mike Hore]

Hi Yves,

Post by Yves Surrel
Hello
I try to create a shared library (named MySharedLib ) with PowerMops
5.5, using
***********
:entry MyEntry { -- }
10 beep
;entry
************
************
library MySharedLib
libcall MyEntry { -- }
MyEntry
************

Off the top of my head it looks all right so far...

Post by Yves Surrel
Error # 220 Couldn't load shared library - see value system_err# for
error
system_err# .
-2804

Which means "Library name not found in frag registry"

Post by Yves Surrel
What is wrong? I have put MySharedLib in the same directory as
PowerMops (btw, what are the commands equivalent to chdir and dir in
PM?)

There aren't any. When you open a file it uses the list of
paths to try that is in the file Mops.paths.

It should work in the PowerMops folder, or the Extensions
folder if you're under OS9, or the appropriate place under
OSX which I'd have to look up.

Anyway I'm very tied up this week so maybe somebody else
can help.

Post by Yves Surrel
Labview does not find the entry MyEntry in MySharedLib either.

Labview? What's that?

Post by Yves Surrel
Thanks for any help. May I have a working example?

I don't seem to be able to locate my test code at the moment
-- sorry.

Cheers, Mike.

----------------------------------------------------------------
Mike Hore ***@OVE.invalid.icasolution.com.au
----------------------------------------------------------------

[Nao Sacrada]

Hello Yves,

[snip]
Error # 220 Couldn't load shared library - see value system_err# for
error
system_err# .
-2804
What is wrong? I have put MySharedLib in the same directory as
PowerMops

I am sorry to say that this seems to be a bug of PowerMops, though it hardly
comes to the front on Mac OS 9.

If you have a resource fork editor, you can get to a temporary fix.
1. Open 'cfrg' ID=0 resource of your library "MySharedLib" with your
resource fork editor, and
2. Set the "Usage" field "0", which would initially be set "1".
3. Save edited resource and close the fork.

PowerMops should become able to "libcall" any entry word in the
SharedLibrary put in the same folder as PowerMops.

But this is not the end of the story. After calling a word
in SharedLibrary, installed AppleEventhandlers, esp. quitapphandler,
seem to be broken. So when you are going to quit PowerMops, do it via
its file menu. Don't quit PowerMops from ApplicationMenu
(PowerMops will crash).
This also seems to be caused from another bug of PowerMops.

These bugs will probably be fixed by the next release of
PowerMops, though I can't give the warranty ;-).

Sincerely,
Nao Sacrada

[Nao Sacrada]

Hello Yves,

[snip]
Error # 220 Couldn't load shared library - see value system_err# for
error
system_err# .
-2804
What is wrong? I have put MySharedLib in the same directory as
PowerMops

I am sorry to say that this seems to be a bug of PowerMops, though it hardly
comes to the front on Mac OS 9.

If you have a resource fork editor, you can get to a temporary fix.
1. Open 'cfrg' ID=0 resource of your library "MySharedLib" with your
resource fork editor, and
2. Set the "Usage" field "0", which would initially be set "1".
3. Save edited resource and close the fork.

PowerMops should become able to "libcall" any entry word in the
SharedLibrary put in the same folder as PowerMops.

But this is not the end of the story. After calling a word
in SharedLibrary, installed AppleEventHandlers, esp. quitapphandler,
seem to be broken. So when you are going to quit PowerMops, do it via
its file menu. Don't quit PowerMops from ApplicationMenu
(PowerMops will crash).
This also seems to be caused from another bug of PowerMops.

These bugs will probably be fixed by the next release of
PowerMops, though I can't give the warranty ;-).

Sincerely,
Nao Sacrada

[Yves Surrel]

Post by Nao Sacrada
I am sorry to say that this seems to be a bug of PowerMops, though it hardly
comes to the front on Mac OS 9.
If you have a resource fork editor, you can get to a temporary fix.
1. Open 'cfrg' ID=0 resource of your library "MySharedLib" with your
resource fork editor, and
2. Set the "Usage" field "0", which would initially be set "1".
3. Save edited resource and close the fork.
PowerMops should become able to "libcall" any entry word in the
SharedLibrary put in the same folder as PowerMops.
But this is not the end of the story. After calling a word
in SharedLibrary, installed AppleEventHandlers, esp. quitapphandler,
seem to be broken. So when you are going to quit PowerMops, do it via
its file menu. Don't quit PowerMops from ApplicationMenu
(PowerMops will crash).
This also seems to be caused from another bug of PowerMops.
These bugs will probably be fixed by the next release of
PowerMops, though I can't give the warranty ;-).
Sincerely,
Nao Sacrada

Nao

Thank you very much for your answer.

I am running Mac OS X (10.3.4). I used to know ResEdit on Mac OS 9,
what is the equivalent in X?

Maybe there is a way to do the fix from within PowerMops using a file
class method?

Yves

[Nao Sacrada]

Hi Yves,

[snip]
I am running Mac OS X (10.3.4). I used to know ResEdit on Mac OS 9,
what is the equivalent in X?

If you have classic environment, ResEdit can run on it
without problem, as far as I know. Using ResEdit is the
easiest way, I think.

But I am sorry, I don't know any resource fork editor
equivalent to ResEdit that runs natively on Mac OS X,
especially if "equivalent" includes "being a freeware" ;-).

Maybe there is a way to do the fix from within PowerMops using a file
class method?

Well, yes, it is possible to correct resource forks with PowerMops,
but not by using a file class method because the file class is
supposing the file object is a data fork file. Instead, we can use
Resource class to edit resource forks on PowerMops.

Anyway, if you please, you could try following code on PowerMops
(excuse me without source code comment)

[code-begin]

variable frefnum
res+ tempcfrg

syscall CloseResFile
syscall RemoveResource

: openresfork ( addr len -- )
0 mopsRsrcDirID 2swap str255 0 HOpenResFile frefnum w! ;

: getcfrgdata
'type cfrg 0 set: tempcfrg
getnew: tempcfrg ;

: changecfrg
get: tempcfrg RemoveResource
0 ptr: tempcfrg 54 + c! \ clear Usage flag
nullOSStr addres: tempcfrg
;

: closeResFork
frefnum w@ CloseResFile ;

: Modifycfrg ( addr len -- )
openresfork
getcfrgdata
changecfrg
closeresfork ;

[code-end]

How to use:
1. put "MySharedLib" in Mops folder
2. load this file into PowerMops. and
3. type on PowerMops

" MySharedLib" Modifycfrg<enter>


This will correct cfrg resource of "MySharedLib".
But there is left another bug I referred to in previous post.
I think this bug resides in a shared library created by
PowerMops, so the AppleEventHandler problem will generally
appear, that is, it will occur also on LabView when
linking to a shared libray generated with PowerMops.
(though, sorry, I know almost nothing about LabView).
Unfortunately I don't know any easy way to fix this
bug without rebuilding PowerMops, which requires,
at least, a classic environment of Mac OS X.


Sincerely,
Nao Sacrada

Yves

[Yves Surrel]

Post by Mike Hore
Hi Yves,

[snip]

Well, yes, it is possible to correct resource forks with PowerMops,
but not by using a file class method because the file class is
supposing the file object is a data fork file. Instead, we can use
Resource class to edit resource forks on PowerMops.
Anyway, if you please, you could try following code on PowerMops
(excuse me without source code comment)
[snip] >
This will correct cfrg resource of "MySharedLib".
But there is left another bug I referred to in previous post.
I think this bug resides in a shared library created by
PowerMops, so the AppleEventHandler problem will generally
appear, that is, it will occur also on LabView when
linking to a shared libray generated with PowerMops.
(though, sorry, I know almost nothing about LabView).
Unfortunately I don't know any easy way to fix this
bug without rebuilding PowerMops, which requires,
at least, a classic environment of Mac OS X.
Sincerely,
Nao Sacrada

Nao

Your patch worked. I am now able to use a shared library generated by
PowerMops from within PowerMops. Unfortunately, Labview (7.0) still
complains and gives a "function not found in library" error (I
respected case). Maybe it's on the Labview side. Do you know of any
tool enabling to explore shared libraries to know what are the
exported entries (as tdump.exe in windoze)?

I have a classic environment on my Mac. I can rebuild Mops if
required; what would by the changes in source files?

Regards


Yves

[ward mcfarland]

Post by Yves Surrel
Unfortunately, Labview (7.0) still
complains and gives a "function not found in library" error (I
respected case). Maybe it's on the Labview side. Do you know of any
tool enabling to explore shared libraries to know what are the
exported entries (as tdump.exe in windoze)?

There is an OS X tool for snooping PEF shared libraries:
/Developer/Applications/Utilities/PEFViewer.app
You have to view some sutff in hex, and I don't find it anywhere near as
useful as the Classic shareware utility called "The Fragmalyzer":
<http://home.mindspring.com/~danwr/downloads/fragmalyzer.html>



Does not the LabView documentation discuss Shared Library requirements?

If LabView for X is Cocoa and not Carbon, it will almost surely not be
able to link to Carbon SharedLibs.

If LabView is expecting to link to a C++ SharedLib, it may expect C++
name mangling in the library (this may be something you can specify in
LabView).


-- w

[Yves Surrel]

Post by ward mcfarland

Post by Yves Surrel
Unfortunately, Labview (7.0) still
complains and gives a "function not found in library" error (I
respected case). Maybe it's on the Labview side. Do you know of any
tool enabling to explore shared libraries to know what are the
exported entries (as tdump.exe in windoze)?

/Developer/Applications/Utilities/PEFViewer.app
You have to view some sutff in hex, and I don't find it anywhere near as
<http://home.mindspring.com/~danwr/downloads/fragmalyzer.html>

I have checked with Fragmalyzer that my shared library exports
MyEntry OK (this was already evident from the fact that it was
possible to import it from PowerMops).

Post by ward mcfarland
Does not the LabView documentation discuss Shared Library requirements?
If LabView for X is Cocoa and not Carbon, it will almost surely not be
able to link to Carbon SharedLibs.

This is probably the point, if the second part of your sentence is
true. Labview 7.0 for macOSX is surely Cocoa...

So I come to a dead end... More and more apps are cocoa, so it is a
real limitation of Mops that it cannot make cocoa-compliant libraries.

Post by ward mcfarland
If LabView is expecting to link to a C++ SharedLib, it may expect C++
name mangling in the library (this may be something you can specify in
LabView).

I don't know precisely about this name mangling; does it concern extra
leading underscore characters in exported symbols or what?

Yves

Post by ward mcfarland
-- w

[ward mcfarland]

Post by Yves Surrel

Post by ward mcfarland
If LabView for X is Cocoa and not Carbon, it will almost surely not be
able to link to Carbon SharedLibs.

This is probably the point, if the second part of your sentence is
true. Labview 7.0 for macOSX is surely Cocoa...

Offhand, I cannot think of an easy way to differentiate between a Mach
(Cocoa) bundled app and a CFM (Carbon) one, although there likely is
one. I could not find any "real" technical specs on LabView at NI's
site, nor what type of shared libraries LV7 requires. Do they supply no
sample libraries nor documentation about building libraries to use with
LV?

Post by Yves Surrel

Post by ward mcfarland
If LabView is expecting to link to a C++ SharedLib, it may expect C++
name mangling in the library (this may be something you can specify in
LabView).

I don't know precisely about this name mangling; does it concern extra
leading underscore characters in exported symbols or what?

Name mangling is often done in C++ and Objective-C to "mangle" the
procedure name with the class it belongs to. It is considered poor form
for a library to export symbols in that form, however.



It would almost surely be possible to adapt Mop's library maker to build
ones that are of a format that could be used from a Mach/Cocoa
application.



Apple Events might work for you, since they are much faster under X than
previously. Unfortunately, the old PPC Toolbox is no longer available,
as that was **very** fast and suitable for passing large blocks of fdata
between applications (probably was deemed too insecure for X, what with
isolated memory spaces, etc). TCPIP would be another method you might
look into and give the added benefit of being able to run client-server
on different machines - it appears that LV supports this.

-- w

[Yves Surrel]

Post by ward mcfarland

Post by Yves Surrel

Post by ward mcfarland
If LabView for X is Cocoa and not Carbon, it will almost surely not be
able to link to Carbon SharedLibs.

This is probably the point, if the second part of your sentence is
true. Labview 7.0 for macOSX is surely Cocoa...

Offhand, I cannot think of an easy way to differentiate between a Mach
(Cocoa) bundled app and a CFM (Carbon) one, although there likely is
one. I could not find any "real" technical specs on LabView at NI's
site, nor what type of shared libraries LV7 requires. Do they supply no
sample libraries nor documentation about building libraries to use with
LV?

I have found the following NI statement about LV7 for MacOSX:

"Shared libraries compiled for Mac OS 9.x or earlier are _not_
compatible with LabVIEW for Mac OS X. You must recompile them in the
Mach-O binary format as a bundle with natural alignment, not the 68k
alignment. Apple provides free developer tools for producing such
binaries."

So I need PowerMops to be able to achieve this...

Post by ward mcfarland
Apple Events might work for you, since they are much faster under X than
previously. Unfortunately, the old PPC Toolbox is no longer available,
as that was **very** fast and suitable for passing large blocks of fdata
between applications (probably was deemed too insecure for X, what with
isolated memory spaces, etc). TCPIP would be another method you might
look into and give the added benefit of being able to run client-server
on different machines - it appears that LV supports this.

You answer to my other post "The same Forth on different OS"!

Cheers

Yves

[ward mcfarland]

Post by Yves Surrel
"Shared libraries compiled for Mac OS 9.x or earlier are _not_
compatible with LabVIEW for Mac OS X. You must recompile them in the
Mach-O binary format as a bundle with natural alignment, not the 68k
alignment. Apple provides free developer tools for producing such
binaries."
So I need PowerMops to be able to achieve this...

Actually, I am fairly sure that PowerMops defaults to building Carbon
PEF libraries, not a Mach-O bundled Frameworks (although someone with
more Mops expertise could correct me here). I think it quite possible
that some enterpising person could force a Mach-O format result.

[Mike Hore]

Post by ward mcfarland

Post by Yves Surrel
"Shared libraries compiled for Mac OS 9.x or earlier are _not_
compatible with LabVIEW for Mac OS X. You must recompile them in the
Mach-O binary format as a bundle with natural alignment, not the 68k
alignment. Apple provides free developer tools for producing such
binaries."
So I need PowerMops to be able to achieve this...

Actually, I am fairly sure that PowerMops defaults to building Carbon
PEF libraries, not a Mach-O bundled Frameworks (although someone with
more Mops expertise could correct me here). I think it quite possible
that some enterpising person could force a Mach-O format result.

Spot on, Ward. PowerMops only knows about building Carbon PEF
libraries. You can CALL frameworks, but not GENERATE them.

I certainly won't have time to even think about this in the
foreseeable future. Any volunteers??

Cheers, Mike.

----------------------------------------------------------------
Mike Hore ***@OVE.invalid.icasolution.com.au
----------------------------------------------------------------