Linking GLIBC statically and proprietary software

I have basic understanding problem with open source and licenses. Could someone please clarify some questions for the below scenario. Excuse me if it is very basic

I'm writing a proprietary software in which i plan to use some open source libraries. I will also need glibc and a C compiler, but did not want to use the default gcc toolchain from my OS, so built my own using crosstools-ng
Now in ct-ng, i guess the libstdc++ library gets linked statically(which is for c++ and i won't be using that in most case i guess) but from my toolchain configuration is my libc statically or dynamically linked? If that is the case, given that glibc is LGPL, and that i can link it to my proprietary software, will this static linking cause any issues to me wrt licensing? Can my software still be close sourced? or do i have to release the compiled objects.

My toolchain configuration is below, from this could someone point to me if glibc is statically or dynamically linked?

Target: x86_64-some-linux-gnu
Configured with: /home/balravin/tools/platform/x86/src/gnu/gcc/4.4.7/.build/src/gcc-4.4.7/configure --build=i686-build_pc-linux-gnu --host=i686-build_pc-linux-gnu --target=x86_64-some-linux-gnu --prefix=/home/balravin/tools/platform/x86/obj/gnu/gcc/4.4.7/x86_64-some-linux-gnu --with-sysroot=/home/balravin/tools/platform/x86/obj/gnu/gcc/4.4.7/x86_64-some-linux-gnu/x86_64-some-linux-gnu/sysroot --enable-languages=c,c++,fortran --with-pkgversion='crosstool-NG 1.15.3' --disable-sjlj-exceptions --enable-__cxa_atexit --enable-libmudflap --enable-libgomp --enable-libssp --with-gmp=/home/balravin/tools/platform/x86/src/gnu/gcc/4.4.7/.build/x86_64-some-linux-gnu/buildtools --with-mpfr=/home/balravin/tools/platform/x86/src/gnu/gcc/4.4.7/.build/x86_64-some-linux-gnu/buildtools --with-ppl=/home/balravin/tools/platform/x86/src/gnu/gcc/4.4.7/.build/x86_64-some-linux-gnu/buildtools --with-cloog=/home/balravin/tools/platform/x86/src/gnu/gcc/4.4.7/.build/x86_64-some-linux-gnu/buildtools --with-host-libstdcxx='-static-libgcc -Wl,-Bstatic,-lstdc++,-Bdynamic -lm' --enable-threads=posix --enable-target-optspace --with-long-double-128 --disable-multilib --with-local-prefix=/home/balravin/tools/platform/x86/obj/gnu/gcc/4.4.7/x86_64-some-linux-gnu/x86_64-some-linux-gnu/sysroot --enable-c99 --enable-long-long
Thread model: posix
gcc version 4.4.7 (crosstool-NG 1.15.3)

There are many reasons, both legal and technical, to make libc.so dynamically linked.

On the legal side, the LGPL license of GNU libc requires you to permit your users to enhance their libc; so if you sell a proprietary software which is statically linked (a technically bad idea), you need to give the means to your user to relink it to a better version of libc; concretely you'll probably need to also give the *.o object of your software.

On the technical side, dynamically linking libc.so is nearly required by all features taking indirectly advantage of libdl.so or of ld.so -i.e. using dynamic linking-, in particular the NSS related functions (like getpwent and getaddrinfo and many others, see nsswitch.conf(5) & nss(5)). Also, dynamically linking libc is much more efficient (the RAM is nearly shared by all processes using libc.so and the executable size is smaller; and most importantly, upgrading libc.so is easier).

BTW, did your company considered making your Linux software free (as in speech)? It does have many advantages, and many companies are choosing the open source route.