Make a plugin working on 4D17 and MAC os x

I have some plugin in working very well up to including 4D16 but they do not work on 4D17.

First message was “L’exécutable n’a pu être chargé”; the answer was easy to find, they were compiled 32bits.

I recompile one of these plugin in 64bits; that did not work better, I received the message “Version incompatible (non étendue). Vous devez mettre à jour votre plugin”

The question is what parameters do I have to change in xCode to become “extended”?

does your plugin define its commands in manifest.json or .RSR?

https://github.com/miyako/4d-plugin-wizard/blob/master/4D_Plugin_Wizard/Resources/readme%20plugin%20sdk%20v14.txt

I use manifest.json.

I almost do not have any thing in .RSR.

Is it possible that the problem is a xCode parameter for compilation or linkage?

Have a good evening

Charles L’Ecuyer

It is literally impossible to say without any information about the project or its settings, but if you suspect that dlopen is failing, you could debug the plugin from Xcode and watch what is printed to console.

https://developer.apple.com/library/archive/documentation/DeveloperTools/Conceptual/DynamicLibraries/100-Articles/LoggingDynamicLoaderEvents.html

but it could be something more basic:

for instance, are you sure you really compiled 64-bit? (you can use the file command from Terminal)

Sorry but I am not familiar with the file command from Terminal.

I joined a file with some screens snap shots.

It is probably a very simple problem but which one

[]34492488;“Some screen shot”[/]

you just launch Terminal, type "file " and drop you plugin executable (inside the plugin)

e.g.

miyako$ file plugin
plugin: Mach-O universal binary with 2 architectures: [x86_64:Mach-O 64-bit bundle x86_64] [i386:Mach-O bundle i386]
plugin (for architecture x86_64): Mach-O 64-bit bundle x86_64
plugin (for architecture i386): Mach-O bundle i386

sometimes, you think you changed the architecture to 64-bits, but the project target settings is different.

I received “Mach-O 64-bit bundle x86_64”

it means the binary is 64-bit.

do you know which version of the plugin SDK you used?

the one on github is v17, but several versions were published along the way: v14, v12, v11.

I do not remember for sure. These plugins worked with 4D version ; originally written in pascal with mpw; they were converted in C and worked with 4D version 8; update for 4d version 11…;

As long as we are in 32bits all worked perfectly.

I am on Sierra (10.12.6) and use XCODE Version 8.2.1 (8C1002).

When 4D starts, it never execute the plain (no init phase). 4D sees the jason file because the entry points appears in the procedure editor but 4D reacts as it do not se the code

I joint one of my plugin zipped.

https://forums.4d.com/4DBB_Main/x_User/2632973/files/34514764.zip

if you run “nm -g”

you would see that the plugin exports “_FourDPack”

it means the plugin was created with the v2004 (or older) SDK.

(since v11 Unicode mode, the entry point is “_FourDPackex”)

Exact: I saw “_FourDPackEX”

In:
4DPluginAPI.def EXPORTS FourDPackex (strange file)
PrivateTypes.h FOURDCALL FourDPackex(PA_long32 selector, void* params, void** data, void* result )

I joined a copy of the result fo nm command

Have a good weekend

https://forums.4d.com/4DBB_Main/x_User/2632973/files/34519823.zip

Yes, FourDPackex in C, but your plugin exports FourDPackEX, which is not the same.

I made the changes every where FourDPackEX for FourDPackex and it began to work well.

I had the idea that the problem was to be an very easy thing and you were excellent in proving it (case sensitivity).

Thanks a lot to you and to MR Keisuke MIYAKO, you permitted me to understand more about the linkage after compilations.