# Libfdb\_c.so size

**URL:** <https://forums.foundationdb.org/t/libfdb-c-so-size/3663>\
**Category:** FoundationDB Core\
**Created:** [November 17, 2022, 6:35pm UTC](https://forums.foundationdb.org/t/libfdb-c-so-size/3663 "2022-11-17T18:35:06Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![tangerine](https://sea1.discourse-cdn.com/foundationdb/user_avatar/forums.foundationdb.org/tangerine/32/1084_2.png) [@tangerine](https://forums.foundationdb.org/u/tangerine)\
**Post date:** [November 17, 2022, 6:35pm UTC](https://forums.foundationdb.org/t/libfdb-c-so-size/3663/1 "2022-11-17T18:35:06Z")

</div>

HI,  
This one maybe a cpack question but I notice that when I compile the FDB source code, the libfdb\_c.so under my build/lib is about 2x bigger then the one I generated using “cpack -G TGZ”. So, why the cpack one is much smaller? Is it because it is a dynamic version and the one build from source is a static link one?  
Thanks,

---

<div class="post-metadata">

**Author:** ![jzhou](https://sea1.discourse-cdn.com/foundationdb/user_avatar/forums.foundationdb.org/jzhou/32/445_2.png) [@jzhou](https://forums.foundationdb.org/u/jzhou)\
**Post date:** [November 18, 2022, 5:04am UTC](https://forums.foundationdb.org/t/libfdb-c-so-size/3663/2 "2022-11-18T05:04:14Z")

</div>

Under build/lib, it’s non-stripped binary. Maybe `cpack` generate stripped binary? You can use `file libfdb_c.so` to tell if it’s stripped or not.

---

<div class="post-metadata">

**Author:** ![tangerine](https://sea1.discourse-cdn.com/foundationdb/user_avatar/forums.foundationdb.org/tangerine/32/1084_2.png) [@tangerine](https://forums.foundationdb.org/u/tangerine)\
**Post date:** [November 18, 2022, 4:24pm UTC](https://forums.foundationdb.org/t/libfdb-c-so-size/3663/3 "2022-11-18T16:24:36Z")

</div>

Based on your suggestion, I compared the 3 libfdb\_c.so that I have generated:  
The one from build/lib which is just resulted from cmake:file …/…/…/lib/libfdb\_c.so  
…/…/…/lib/libfdb\_c.so: ELF 64-bit LSB shared object, x86-64, version 1 (GNU/Linux), dynamically linked, BuildID[sha1]=9a7634a0d21caca67c5dd3f833c9f2d5ea8faa5b, with debug\_info, not stripped

From RPM generated from gpack:  
file …/…/…/lib/libfdb\_c.so  
…/…/…/lib/libfdb\_c.so: ELF 64-bit LSB shared object, x86-64, version 1 (GNU/Linux), dynamically linked, BuildID[sha1]=9a7634a0d21caca67c5dd3f833c9f2d5ea8faa5b, with debug\_info, not stripped

From TGZ generated from gpack:  
ile libfdb\_c.so  
libfdb\_c.so: ELF 64-bit LSB shared object, x86-64, version 1 (GNU/Linux), dynamically linked, BuildID[sha1]=9a7634a0d21caca67c5dd3f833c9f2d5ea8faa5b, stripped

The stripped version from TGZ is the smallest of the 3. It is only 7682208 in size.  
The RPM version, even though it is not stripped and have debug\_info, comes in second: 10728704  
The compile non-stripped version is 189015776  
Stripped being the smallest, that make sense. But non-stripped and have debug\_info that is smaller then just non-stripped is a bit confusing.

---

<div class="post-metadata">

**Author:** ![jzhou](https://sea1.discourse-cdn.com/foundationdb/user_avatar/forums.foundationdb.org/jzhou/32/445_2.png) [@jzhou](https://forums.foundationdb.org/u/jzhou)\
**Post date:** [November 18, 2022, 5:43pm UTC](https://forums.foundationdb.org/t/libfdb-c-so-size/3663/4 "2022-11-18T17:43:29Z")

</div>

It’s weird build/lib and RPM have different sizes. I can’t explain it if they compiled with the same flags.