The following issues found are based on a design using LPC1788 with external SDRAM on the EMC bus. It has an RTOS resides in the internal Flash, while the emWin application runs from the external SDRAM. The emWin application is built as an relocatable ELF binary.
(1) In the situation of running emWin application from external SDRAM (address starting at 0xA0000000), emWin calls the RTOS functions (such as memcpy) which reside in the internal flash memory (address starting at 0). The function calls fail. It seems that emWin pre-built library is not built with -mlong-calls. We have confirmed that JMP24 is observed.
We suggest Segger include -mlong-calls in building the emWin library, since the use of external SDRAM is quite common in many applcations. If anyone hits this scenario, the emWin library is broken in that sense.
(2) A less serious issue is the -fno-common is not in building the emWin library either. It is a fact that not all RTOS or maybe some flavors of embedded Linux support common section.
Your prompt response will be really appreciated.
Thanks.

It is quite interesting. I opened a support ticket with NXP. After a long long wait, their answer to this question is NXP does *NOT* have source code of the emWin, so they do NOT build them. They asked me to seek support from Segger.
Now, I am confused by being pushed back and forth. I have to tell you. This becomes ridiculously painful to get help....sigh.

Hi Adrian,
I am not blaming you or Segger for the pain I have with NXP or ST. I am simply tired of waiting for almost half a month for something we have confirmed is the problem but still no real answer from NXP and being pushed back and forth. I have contacted the NXP customer care representative for the poor support they have.
To answer you questions,
- Did persons from NXP/ST tell you to ask Segger for support? If yes, who?
A: I wish I know his/her name. I opened a support ticket. The case number is 00050347. Not that I think you can do anything for their ticket, but just to prove I am not whining. All I got is some useless response from the anonymous support person. Here is the copy & paste from the response for your fun:
"Got your situation. The emWin is designed and provided by Segger and we have not source codes but library. It is, the requirement needs to submit to Segger for a revision. It's not quick and convenient for the global tech support here to do it...."

Then it pointed to some social media sites for us to seek support, which seems quite like a joke.

- Did a person from NXP/ST tell you that they do not build their libraries? If yes, who?
See above...

- Could you please provide me with the e-mail conversation or with a link to the according thread in the NXP/ST support forum?
The case was raised as a support ticket after we searched for local help but no really anything relevant.
I really appreciate it that you are standing up for supporting us. I know you are going out of your way to help NXP or ST customers.
The issue I am having is that we have a design that uses the external SDRAM (at 0xA0000000) to run the application linked with emWin library. There is RTOS residing in internal flash (at address of zero). We found that the emWin library seems built without -mlong-calls, because there are calls from emWin, such as memcpy, strcpy etc. that are resolved with JMP24 by the ELF loader. We just need them to confirm this and request a build with -mlong-calls turned on. I don't think it will cause future compatibility issue since the APIs are not being changed at all. The change should be transparent to users.
Thanks for your help.

Hi Adrian,
Really appreciate it!