Why do all ADI FreeRTOS examples and instructions include libssl even though the documentation explicitly warns against this?

The Release Notes for ADI FreeRTOS 1.4.0 say this.

As of the 1.3.1 release of the Analog Devices FreeRTOS product the pre-built versions of the System Services and Devices Driver libraries are no longer compatible with FreeRTOS for the ADSP-SC5xx and Blackfin BF7xx platforms. In order to use the System Services and Device Drivers the project must include the source versions of these libraries rather than linking against the pre-built versions of the libraries.

They also contain this big block warning circled in red.

Attempting to use the pre-built versions of the System Services and Device Driver libraries may result in application corruption and run time execution failure.

The User's Guide for ADI FreeRTOS has a section called "Using CrossCore Embedded Studio System Services and Device Drivers with FreeRTOS".  It has similar warnings to the above release notes and also provides a guide to avoid loading the default libraries for Device Drivers and System Services.

However, the instructions provided for both the ARM and Sharc only avoid loading the pre-built version of the Device Driver library (libdrv).  They provide no guidance on how to remove the pre-compiled System Services library (libssl).

Looking through the resulting map files of several different ADI-provided ARM examples, you can see many functions being pulled from libssl.  For example...

c:/analog devices/crosscore embedded studio 2.9.3/arm/arm-none-eabi/bin/../lib/gcc/arm-none-eabi/7.2.1/../../../../arm-none-eabi/lib/sc589_rev_any_mt\libssl.a(adi_dma.o)
                              system/drivers/uart/adi_uart.o (adi_pdma_Open)
c:/analog devices/crosscore embedded studio 2.9.3/arm/arm-none-eabi/bin/../lib/gcc/arm-none-eabi/7.2.1/../../../../arm-none-eabi/lib/sc589_rev_any_mt\libssl.a(adi_gic.o)
                              system/osal/ARM-Cortex-A/adi_osal_arch_c.o (adi_gic_SetIntPriority)
c:/analog devices/crosscore embedded studio 2.9.3/arm/arm-none-eabi/bin/../lib/gcc/arm-none-eabi/7.2.1/../../../../arm-none-eabi/lib/sc589_rev_any_mt\libssl.a(adi_int.o)
                              system/drivers/uart/adi_uart.o (adi_int_InstallHandler)
c:/analog devices/crosscore embedded studio 2.9.3/arm/arm-none-eabi/bin/../lib/gcc/arm-none-eabi/7.2.1/../../../../arm-none-eabi/lib/sc589_rev_any_mt\libssl.a(adi_pwr.o)
                              system/FreeRTOS/portable/io_startup.o (adi_pwr_Init)
c:/analog devices/crosscore embedded studio 2.9.3/arm/arm-none-eabi/bin/../lib/gcc/arm-none-eabi/7.2.1/../../../../arm-none-eabi/lib/sc589_rev_any_mt\libssl.a(adi_tmr.o)
                              system/drivers/uart/adi_uart.o (adi_tmr_Open)

Now for a few of these (PWR, TMR, and DMA), there are services that can be added to the project that will create local virtual folders so that the code will be properly locally compiled, and will disappear from the above listing.  That still leaves adi_gic_SetIntPriority and adi_int_InstallHandler, neither of which have a listed Service Add-in.  (Both could probably be handled by a new service called INT that virtually linked in "services\Source\int\adi_int.c", I'm guessing.)

So I'd like some clarification from ADI.  Is it true that libssl is problematic for use with FreeRTOS?  If so, can an INT service and specs files and compiler flags be provided to avoid linking it?  If not, can the documentation be changed to reflect that libssl is not a problem?

If the answer is actually "yes and no", meaning some parts are dangerous, some aren't, please describe exactly what problem is being avoided here.  I tried to figure this out by examining the differences between 1.2.0, 1.3.0, 1.3.1, and 1.4.0, but there are so little real changes in the ADI provided code between these versions that I can't figure out the problem ADI is trying to avoid.  Most likely, there has always been a problem, but version 1.3.1 addressed it by not loading the default libdrv.

There must be some header file change or a macro definition change that affects the driver/service library code when compiling for FreeRTOS.  Can ADI tell us what that is?

Thanks for any info or discussion.