But that is not possible in my case

Yes, it is.

You must either build the application to match your desired target environment, or you must make your target environment satisfy the requirements of that applicaition you built.

One way to make the application match target environment is to build it in a chroot or a docker container that matches the target.

that is why i have built stand alone application with pyinstaller.

You are not building a "stand alone" application. You are building something that depends on GLIBC-2.14, and trying to run it on a system that doesn't have that (or newer) version of GLIBC.

I need to run this application in 'n' no.of servers, so upgrading glibc is not possible

Sure it is. You are running your application on ancient GLIBC version (version 2.14 was released in 2011). Since then, many CVEs have been discovered and fixed. By continuing to use ancient version, you are exposing your company to significant risks.

So why am I getting GLIBC_2.14 error?

Because your program depends on a symbol with that version, and you are running it on a system which doesn't provide it.

Shouldn't it be 2.19 error?

No.

When a new symbol is introduced, it gets a version assigned to it. Usually that version is the not yet released glibc version, i.e. if the current released version is 2.13, the new symbol gets version 2.14 assigned to it.

That version stays with this symbol (unless a new and incompatible version of the same symbol is introduced later).

The x86_64 GLIBC-2.19 has the following versioned symbols:

$ objdump -T /lib/x86_64-linux-gnu/libc.so.6 | grep ' g ' | head
0000000000078110 g    DF .text  0000000000000124  GLIBC_2.2.5 putwchar
0000000000096a70 g    DF .text  0000000000000020  GLIBC_2.2.5 __strspn_c1
000000000010a2b0 g    DF .text  0000000000000010  GLIBC_2.4   __gethostname_chk
0000000000096a90 g    DF .text  000000000000001a  GLIBC_2.2.5 __strspn_c2
0000000000110570 g    DF .text  00000000000000a5  GLIBC_2.2.5 setrpcent
00000000000a7ba0 g    DF .text  000000000000000a  GLIBC_2.2.5 __wcstod_l
0000000000096ab0 g    DF .text  0000000000000022  GLIBC_2.2.5 __strspn_c3
00000000000fa950 g    DF .text  0000000000000021  GLIBC_2.3.2 epoll_create
000000000010a2c0 g    DF .text  0000000000000010  GLIBC_2.4   __getdomainname_chk
00000000000fab60 g    DF .text  0000000000000021  GLIBC_2.2.5 klogctl
....

That is, if I link a program that calls putwchar, I will need at minimum version 2.2.5, but if my program also calls epoll_create, then I will need a minimum version of 2.3.2.

Your program calls some symbol with version GLIBC_2.14, most likely this one:

0000000000091620 g   iD  .text  000000000000003d  GLIBC_2.14  memcpy

Your program is known to not call any of the symbols below (or you would have gotten a different required version):

$ objdump -T /lib/x86_64-linux-gnu/libc.so.6 | egrep 'GLIBC_2.1[5-9]'
000000000010ab30 g    DF .text  0000000000000014  GLIBC_2.16  __ppoll_chk
00000000001087d0  w   DF .text  000000000000003e  GLIBC_2.17  clock_getcpuclockid
000000000010aaf0 g    DF .text  0000000000000017  GLIBC_2.15  __fdelt_warn
000000000010aaf0 g    DF .text  0000000000000017  GLIBC_2.15  __fdelt_chk
000000000003c6b0 g    DF .text  00000000000000fc  GLIBC_2.18  __cxa_thread_atexit_impl
00000000000fb070 g    DF .text  0000000000000024  GLIBC_2.15  process_vm_writev
00000000000bd420 g    DF .text  00000000000001ba  GLIBC_2.15  scandirat
00000000000af970 g    DF .text  0000000000000019  GLIBC_2.16  c16rtomb
00000000001088f0  w   DF .text  0000000000000090  GLIBC_2.17  clock_nanosleep
00000000000af6e0 g    DF .text  0000000000000282  GLIBC_2.16  mbrtoc16
00000000000a3c70  w   DF .text  0000000000000230  GLIBC_2.16  mbrtoc32
0000000000000000 g    DO *ABS*  0000000000000000  GLIBC_2.15  GLIBC_2.15
0000000000000000 g    DO *ABS*  0000000000000000  GLIBC_2.16  GLIBC_2.16
0000000000000000 g    DO *ABS*  0000000000000000  GLIBC_2.17  GLIBC_2.17
0000000000000000 g    DO *ABS*  0000000000000000  GLIBC_2.18  GLIBC_2.18
00000000000b9f40 g    DF .text  0000000000000042  GLIBC_2.16  timespec_get
0000000000083120  w   DF .text  0000000000000009  GLIBC_2.16  aligned_alloc
0000000000108810  w   DF .text  0000000000000025  GLIBC_2.17  clock_getres
0000000000108880  w   DF .text  0000000000000064  GLIBC_2.17  clock_settime
00000000000f8240  w   DF .text  0000000000000068  GLIBC_2.16  getauxval
00000000000e44f0 g    DF .text  0000000000000015  GLIBC_2.15  posix_spawn
0000000000108840  w   DF .text  000000000000003b  GLIBC_2.17  clock_gettime
00000000000a3ea0  w   DF .text  00000000000001ea  GLIBC_2.16  c32rtomb
000000000003c0b0  w   DF .text  000000000000001b  GLIBC_2.17  secure_getenv
000000000010ab10 g    DF .text  0000000000000014  GLIBC_2.16  __poll_chk
00000000000f8240 g    DF .text  0000000000000068  GLIBC_2.16  __getauxval
00000000000fb040 g    DF .text  0000000000000024  GLIBC_2.15  process_vm_readv
00000000000bd420  w   DF .text  00000000000001ba  GLIBC_2.15  scandirat64
00000000000e4510 g    DF .text  0000000000000015  GLIBC_2.15  posix_spawnp

@rokm will know more about this than me but generally copying system libraries like glibc rarely works. You're better off finding a Python built with a lower glibc requirement which in practice means building on an old version of Linux or an old docker image. cdrx/docker-pyinstaller is a bit out of date but is otherwise ideal for this.

Cyrhon FAQ section says:

Under Linux, I get runtime dynamic linker errors, related to libc. What should I do? The executable that PyInstaller builds is not fully static, in that it still depends on the system libc. Under Linux, the ABI of GLIBC is backward compatible, but not forward compatible. So if you link against a newer GLIBC, you can't run the resulting executable on an older system. The supplied binary bootloader should work with older GLIBC. However, the libpython.so and other dynamic libraries still depends on the newer GLIBC. The solution is to compile the Python interpreter with its modules (and also probably bootloader) on the oldest system you have around, so that it gets linked with the oldest version of GLIBC.

and

How to get recent Python environment working on old Linux distribution? The issue is that Python and its modules has to be compiled against older GLIBC. Another issue is that you probably want to use latest Python features and on old Linux distributions there is only available really old Python version (e.g. on Centos 5 is available Python 2.4).

You don't have a high enough version of libc6, that is causing the error.

From How to fix “/lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.14' not found”? – Super User:

That means the program was compiled against glibc version 2.14, and it requires that version to run, but your system has an older version installed. You'll need to either recompile the program against the version of glibc that's on your system, or install a newer version of glibc (the "libc6" package in Debian).

So, you just need to upgrade your libc6 package. All versions of Ubuntu have at least version 2.15 because it's a faily important package (reference).

To upgrade it, use these commands in a terminal:

sudo apt-get update
sudo apt-get install libc6

That means the program was compiled against glibc version 2.14, and it requires that version to run, but your system has an older version installed. You'll need to either recompile the program against the version of glibc that's on your system, or install a newer version of glibc (the "libc6" package in Debian).

Debian has glibc 2.16 in the "experimental" repository, but recompiling the program is the safer option. Glibc is the library that everything depends on, so upgrading it can have far-reaching implications. Although there's probably nothing wrong with Debian's glibc 2.16 package, the fact that it's in the experimental repository means it hasn't received as much testing.

You could try to install glibc 2.14 in a specific path and force it with an env variable:

export LD_LIBRARY_PATH=/home/user/.usr/lib

Check this answer about how to do it:

How to upgrade glibc from version 2.12 to 2.14 on CentOS?

what is your distrib, and which version?