# What's the point of having libc_pic.a in the base system if the library is completely unusable?



## Oleg_NYC (Aug 16, 2017)

What's the point of having libc_pic.a in the base system if the library is completely unusable? If I have this code 
	
	



```
int main(){}
```
 and compile it using the command `clang -nodefaultlibs /usr/lib/libc_pic.a file.c` then I get a segmentation fault.


----------



## ralphbsz (Aug 16, 2017)

Please don't post complaints without giving sufficient details.  Most importantly: What version are you running?  This might be the known bug 218395, or a close relative.  I don't know which versions that bug exists in, when it was introduced, and when it will be fixed.

What are you really trying to accomplish?  This could also be pilot error (using a combination of flags that is not supported).

By the way, your program is borderline incorrect (although legally correct).  You have declared the main() function to return an int, yet it is lacking a return statement.  Turns out that somewhere buried in the C standard there is a special exemption that says that if main() has no return statement, it will implicitly use "return 0".  I think the answer is different for C++; the rules for main() are somewhat different there: due to static constructors and stuff like that, I think in C++ main() should not be reentrant.  In any case, from a style point of view, it would have been nicer to write your program like this: "void main(){}".  Probably makes no difference to linking with the PIC library though.


----------



## Oleg_NYC (Aug 16, 2017)

This issue exists on both 11.1-RELEASE and 12.0-CURRENT. I am not really trying to accomplish anything; I am just curious why the code segfaulted when it executed. I don't have the issue that was reported for bug 218395.


----------



## abishai (Aug 17, 2017)

Linking against libc_p.a works.


----------



## Oleg_NYC (Aug 17, 2017)

Well, what purpose does libc_pic.a serve?


----------



## ralphbsz (Aug 18, 2017)

libc_p is the version of libc with profiling (performance measurement) enabled.  Linking for profiling is useful, if one wants to measure (and presumably improve) the performance of libc.

libc_pic is the version of libc compiled for position-independent code.  Position-independent code is not used for building executables, as it would be pointless: executables work perfectly well without being position-independent.  It is used for building libraries that can be loaded (typically dynamically at runtime).

If you don't know what profiling or position-independent means, then ... I don't have time tonight to write a long textbook about that.  There must be documentation on the web.

That gets me back to my question of what are you trying to accomplish.  Linking an executable that's position-independent doesn't accomplish anything.  Fundamentally, you used options or command line switches that don't work, and I don't think are intended to work.  Why did you do that?


----------



## Oleg_NYC (Aug 18, 2017)

Okay, I finally succeeded in creating an executable that doesn't segfault. Let me show you the steps that I took before achieving that milestone. I created file.c with the code 
	
	



```
void func(); int main() { func(); }
```
. Then I created file1.c with the code 
	
	



```
#include <stdio.h>
void func() { puts("Hello world"); }
```
. Then I compiled file1.c using the command `clang -shared -nodefaultlibs /usr/lib/libc_pic.a -fPIC -Wl,--version-script,script file1.c -o file1.so`. Then I created an executable with the command `clang file.c file1.so -nodefaultlibs -Wl,-rpath,./`. When I ran this program, it didn't segfault! Before I created file1.so, I needed a version script because I was getting the errors 
	
	



```
/usr/bin/ld: error: /usr/lib/libc_pic.a(jemalloc_jemalloc.pico): symbol _malloc_options@FBSD_1.0 has undefined version FBSD_1.0
/usr/bin/ld: error: /usr/lib/libc_pic.a(jemalloc_malloc_io.pico): symbol _malloc_message@FBSD_1.0 has undefined version FBSD_1.0
```
. I created script with the contents 
	
	



```
FBSD_1.0 {
};
```
 and ran the command that I mentioned earlier. I am a bit embarrassed now that I called libc_pic.a "completely unusable". You have to forgive me because I am still a n00b.
 You asked me what I was trying to accomplish. I didn't have a specific goal. I wanted to increase my knowledge about computer-related stuff. I still don't really understand anything about version scripts; I was simply lucky that the linker didn't complain about the script that I wrote.
 Now it's 3:47 am and I really have to get some sleep now...


----------



## Oleg_NYC (Aug 20, 2017)

I wonder why the base system doesn't have a pic-enabled libc++ library.


----------

