Anyone using the clang C++ compilers with Nexus?

Hello,

I started the migration process for one of my apps, from RAD Studio 10.1
to 10.3 (right now, although the end objective is the newest version).
It went quite easy, not the kind of pains I used to have before.

I have been working with 32bit apps forever. So one of the ideas is to
make the jump at some point into 64 bit apps. Mostly for the server part
of the app, which is another part I am reengineering.

Just for kicks, I tried using the new 32 bit compiler, based on clang
(at the end I hope it's going to be more or less the same than creating
the 64 bit version...) After fixing some issues, I ended up with a
showstopper at linking time, in the first big Nexus intensive project,
which I think it's related to this:

https://quality.embarcadero.com/browse/RSP-35203

At least the error message it's the same:

Error: Unresolved external '__tpdsc__ EnxDatabaseError'

The previous projects in that project group do use Nexus, but they don't
use the Exception nor any derived class themselves.

Seeing that this was solved later (11.1 it's the one it mention solves
this) I decided to wait with that part of the project until installing
the newest version, but I wonder if somebody here is using C++Builder
with the new compilers and Nexus without problems?

Thanks!

Rodrigo Gómez

[AndyPhotoBell]

Rodrigo

Sorry for the very late reply...

I've been using the free embedded Nexus in C++ Builder 11.3, Clang compiler, without errors, providing I link with runtime packages.

I've just upgraded to the paid embedded version and have a successful 64 bit test app, again needing runtime package linking.

I'm going to spend time this week converting my main nexus-using app to 64 bit. As there's quite a few 3rd party components in it, I expect it to take a while to complete the conversion, but will post my findings once I complete the task.

Andy

Hello Andy,

Thanks for the feedback!

I managed to compile and run my biggest app with the Clang compiler
around the same time I asked the question. But I did have to fix several
things on the Nexus headers by hand. Some of the changes I could provide
Nexus with the modified PAS units (some were $HPPEMIT directives that
were very outdated and no longer needed) but some others I could not
find a way to change the Delphi code for it to produce correct
headers... I am not sure what was the problem, if it was only related to
PreCompiled Headers use or something more complex... I'll try to make
time to review them again.

Hopefully the next Nexus version would have the few changes I was able
to send.

Thanks!

AndyPhotoBell wrote on 27/08/2023 03:40 p. m.:
> Rodrigo
>
> Sorry for the very late reply...
>
> I've been using the free embedded Nexus in C++ Builder 11.3, Clang
> compiler, without errors, providing I link with runtime packages.
>
> I've just upgraded to the paid embedded version and have a successful 64
> bit test app, again needing runtime package linking.
>
> I'm going to spend time this week converting my main nexus-using app to
> 64 bit. As there's quite a few 3rd party components in it, I expect it
> to take a while to complete the conversion, but will post my findings
> once I complete the task.
>
> Andy
>
>

HelloÂ*Andy,

ThanksÂ*forÂ*theÂ*feedback!

I managed to compile and run my biggest app with the Clang compiler
around the same time I asked the question. But I did have to fix several
things on the Nexus headers by hand. Some of the changes I could provide
Nexus with the modified PAS units (some were $HPPEMIT directives that
were very outdated and no longer needed) but some others I could not
find a way to change the Delphi code for it to produce correct
headers... I am not sure what was the problem, if it was only related to
PreCompiled Headers use or something more complex... I'll try to make
timeÂ*toÂ*reviewÂ*themÂ*again.

Hopefully the next Nexus version would have the few changes I was able
toÂ*send.

Thanks!

AndyPhotoBellÂ*wroteÂ*onÂ*27/08/2023Â*03:40Â*p.Â*m.:
> Rodrigo
>
> SorryÂ*forÂ*theÂ*veryÂ*lateÂ*reply...
>
> I'veÂ*beenÂ*usingÂ*theÂ*freeÂ*embeddedÂ*NexusÂ*in *C++Â*BuilderÂ*11.3,Â*Clang
> compiler,Â*Â*withoutÂ*errors,Â*providingÂ*IÂ*link *withÂ*runtimeÂ*packages.
>
> I'veÂ*justÂ*upgradedÂ*toÂ*theÂ*paidÂ*embeddedÂ*ver sionÂ*andÂ*haveÂ*aÂ*successfulÂ*64
> bitÂ*testÂ*app,Â*againÂ*needingÂ*runtimeÂ*package *linking.
>
> I'mÂ*goingÂ*toÂ*spendÂ*timeÂ*thisÂ*weekÂ*convertin gÂ*myÂ*mainÂ*nexus-usingÂ*appÂ*to
> 64Â*bit.Â*AsÂ*there'sÂ*quiteÂ*aÂ*fewÂ*3rdÂ*partyÂ* componentsÂ*inÂ*it,Â*IÂ*expectÂ*it
> toÂ*takeÂ*aÂ*whileÂ*toÂ*completeÂ*theÂ*conversion, Â*butÂ*willÂ*postÂ*myÂ*findings
> onceÂ*IÂ*completeÂ*theÂ*task.
>
> Andy
>
>

[AndyPhotoBell]

Originally Posted by Rodrigo Gómez Córdova

Hello Andy,

Thanks for the feedback!

...

No worries.

I, too, had to make quite a few changes to the generated .hpp files, but this didn't seem to have any negative impact...

Other than that, it's wortking ok for me.

At least one of the 64 bit libraries produced by the Delphi compiler has errors in it, which is why linking must include dynamic runtime packages. It's not a Nexus error - it's a known fault with the Delphi compiler. Embarcadero hope RAD Studio 12 will fix this...

Andy

[AndyPhotoBell]

I've found with 32 bit C++ Builder 11 apps, I have to link with runtime packages and include ALL packages in the runtime list, not just Nexus's and basic VCL ones.

Embarcadero support told me:

1) packages were a Delphi construct.
2) this means it needs to initialise the units (another Delphi construct) in a specific order, which is not the same as for C/C++ modules. This is what "#pragma package(smart_init)" does.
3) so when the VCL starts it will cycle through the initialisation sections of the units, calling them one by one.
4) static libraries necessarily needs to be initialised differently, this has means you can have out of sequence initialisation of units, which is obviously a problem. I am guessing this is what you are seeing.

In Classic this was less of an issue, as we controlled much of how the compiler interacted with the Delphi runtime but with clang we have to bend to the how LLVM/CLANG wants things to be done.

With regard to the 32 bit app not working if statically linked they told me:

"It is the initialisation of the startup/exit routines all Delphi units have an "initialization" and a "finalization" section, and these are called out of sequence. So you can imagine in some situations you can get a double release on a resource.
NexusDB should investigate the weak package linking to make it work, but it normally is a LOT of work, for little payback."

And they pointed me at these links:

https://docwiki.embarcadero.com/RADS...Pragma_package

https://docwiki.embarcadero.com/RADS...pragma_startup

So, it seems C++ Builder 32 bit *could* be made to work with static linking, but it would be a lot of effort (and changes to the Delphi code) to do so...