Probably bad libbrx22.so library in 22 linux toolkit

Massimo Del Fedele

Linking with given one (BRXSDK_linux_Bcad_V22.1.05/lib64/libbrx22.so, size 34700928, date 15/11/2021) brings linker errors on some Civil functios.
Using the one provided with Bricscad setup (/opt/bricsys/bricscad/v22/libbrx22.so, size 35527320, date 5/5/2022) linking is ok.
I'm on the way of testing the BRX sdk, so still not sure if the remaining is ok.

Torsten Moses

yes, that sounds normal, as V22.2 brings several extensions, also in APIs ...
in generally, BRX SDK is backward-compatible, meaning : using older V22 SDK will work in newer BricsCAD V22 versions, but not th eother way around.

So using the V22.2 BRX SDK will require a BricsCAD V22.1.xx :-)
many greetings !

Massimo Del Fedele

Torsten Moses said:

yes, that sounds normal, as V22.2 brings several extensions, also in APIs ...
in generally, BRX SDK is backward-compatible, meaning : using older V22 SDK will work in newer BricsCAD V22 versions, but not th eother way around.

So using the V22.2 BRX SDK will require a BricsCAD V22.1.xx :-)
many greetings !

Ehmmm... I'm using 22.2.04 bricscad ultimate (trial) and latest 22 linux sdk, so it should work anyways.
What I see is that the libbrx22 inside the SDK is OLDER than the version inside bricscad's folder, but brings linker errors. I guess it's a left-over of some previous builds.
The weird stuff is that now it works also with older library... don't know why. Yesterday I spent a whole day with linker errors (4 of them), now they're gone.

BTW, I noticed that Bricscad caches BRX applications, so if I load an app, unload it, rebuild it and reload it, it will use the previous version. By now the only way to fix it is to close bricscad and re-open it.
Is there a way to disable arx applications cache during development ?

Torsten Moses

Dear Massimo,

under Linux, there is no real difference between a "lib" and a "DLL" . the libbrx22.so is both : you can link against it, and you can load it ...
therefore, a newer V22.2 BricsCAD Linux version naturally has its up-to-date created libbrx22.so (as internal "DLL" module) - while the SDK contains the "official library" module, as built at the time of first V22.2 ...
BRX SDK is created not for every sub-version, only for main 22.1 and 22.2 BricsCAD.

Therefore, a newer BricsCAD contains a newer libbrx22.so, than the SDK ... but the newer is compatible with the older, so that modules linked against the SDK module will also work in newer BricsCAD, with newer libbrx22.so module.

> BTW, I noticed that Bricscad caches BRX applications, so if I load an app, unload it, rebuild it and reload it, it will use the previous version. By now the only way to fix it is to close bricscad and re-open it.

No, it is not "caching" :-)
Only explanation I have is, that unloading your "xxx.so" module does not finally unload the module from memory, if any reference to created data/objects is pending ...
such can happen, if your module does not delete *any* dynamically created data objects, at kUnloadApp stage ... when dynamically created data are still alive (not deleted yet), then the module can not be physically unloaded - though it is unloaded in logical sense, say (arx) function at prompt does no longer list your module ...

Only way to solve : ensure that any dynamically object is finally deleted when kUnloadApp message is called for your acrxEntryPoint() function.

hope this explains a bit ...
many greetings !

Massimo Del Fedele

Torsten Moses said:

Dear Massimo,

under Linux, there is no real difference between a "lib" and a "DLL" . the libbrx22.so is both : you can link against it, and you can load it ...
therefore, a newer V22.2 BricsCAD Linux version naturally has its up-to-date created libbrx22.so (as internal "DLL" module) - while the SDK contains the "official library" module, as built at the time of first V22.2 ...
BRX SDK is created not for every sub-version, only for main 22.1 and 22.2 BricsCAD.

Therefore, a newer BricsCAD contains a newer libbrx22.so, than the SDK ... but the newer is compatible with the older, so that modules linked against the SDK module will also work in newer BricsCAD, with newer libbrx22.so module.

The problem was of some other kind. I couldn't link against older libbrx, but newer worked.
Anyways now it's ok

I'm using a VERY small demo code... just adds a command that prints something using acUtPrintf.
Just ONE command, and a couple of messages when loading and unloading the brx app.
NO objects created, no allocation, nothing.
But it stil "caches" the code. I have to quit bricscad and re-run it... unloading and reloading the brx is not enough.

Ciao
Massimo

Torsten Moses

Dear Massino,

> NO objects created, no allocation, nothing.
> But it stil "caches" the code. I have to quit bricscad and re-run it... unloading and reloading the brx is not enough.

ok, I see, thanks for your explanations ...
have you checked 8arx) output whether your module is still listed after unloading your .brx/.lrx module ?
How do you unload - by APPLOAD or by (arxunload) ?

That "caching" is still that the module was not really unloaded ...
you might add a prompt message to axrcEntryPoint() at kUnloadApp event :
- is it reached ?
- it might be possible that our BRX sample code does not do a full + complete release of all objects, hence pending references ...

Key point is : does (arx) still reports your module ?
if not, can you delete your .brx/.lrx module as a file, on disk ? (likely not ?)

many greetings !

Massimo Del Fedele

Torsten Moses said:

Dear Massino,

have you checked 8arx) output whether your module is still listed after unloading your .brx/.lrx module ?
How do you unload - by APPLOAD or by (arxunload) ?

That "caching" is still that the module was not really unloaded ...
you might add a prompt message to axrcEntryPoint() at kUnloadApp event :
- is it reached ?
- it might be possible that our BRX sample code does not do a full + complete release of all objects, hence pending references ...

I tried both, the app IS unloading (it calls kUnloadApp event, I've an acUtPrintf() there) in both cases.

Key point is : does (arx) still reports your module ?

nope... after unloading (arx) doesn't list the app anymore

if not, can you delete your .brx/.lrx module as a file, on disk ? (likely not ?)

Yes I can, but I also can delete it if it's loaded, I guess under linux there's no locking mechanics of file on disk.

Resuming :

I can load both by appload or (arxload "path")
I can unload both by appload or (arxunload "name")
When loaded it lists on (arx), when unloaded it doesn't
Load/unload hooks (kLoadApp / kUnloadApp) are correctly executed

BUT
If I unload, modify, recompile and load the app again I see that the OLD version is still used.
To have the new version I must quit and restart bricscad.

Best regards

Massimo

Torsten Moses

Dear Massimo,

thanks for testing & feedback !

> If I unload, modify, recompile and load the app again I see that the OLD version is still used.
> To have the new version I must quit and restart bricscad.

yes, I see ... sounds that there is either a kind of generic problem under Linux and/or a problem of BricsCAD/BRX handling of plugin-modules ...
you might open a support request, so that our colleagues can also try to reproduce (i.e. with brxSample, or other simple BRX module(s) from our test system), to understand why next (arxload) does not load the new module ...

thanks & many greetings !