# How do you recompile with -fPIC ?



## rtwingfield (Feb 4, 2016)

I started with a simple invocation of `portmaster apache24`.  After much rattling around, the system is now halting at this point.  How do you tell portmaster to recompile the damn thing with 
	
	



```
-fPIC
```
as suggested by the following diagnostic.



> /usr/local/bin/ld: /usr/lib/crt1.o: relocation R_X86_64_32 against `_DYNAMIC' can not be used when making a shared object; recompile with -fPIC
> /usr/lib/crt1.o: error adding symbols: Bad value
> collect2: error: ld returned 1 exit status
> Makefile:401: recipe for target 'tcsd' failed
> ...



Honestly, I don't know how `portmaster` uses compiler arguments, etc.  Where does it gather them up . . .from /etc/make.conf?


----------



## Oko (Feb 4, 2016)

You should not be compiling anything.

`pkg install apache24`


----------



## rtwingfield (Feb 4, 2016)

Oko said:


> You should not be compiling anything.
> 
> `pkg install apache24`



NO??  Compiling generates code that is custom to the hardware platform and environment.  Also, you should know that there are sundry options associated with a complex application such as Apache that a generically compiled _one-size-fits-all_ package install will not accommodate.

So back to my original simple question, "How to direct portmaster to recompile with -fPIC?"

Can somebody just answer my question?


----------



## marino (Feb 4, 2016)

You don't.  That's not an error you should get, so there's a problem with the port.

also, the error message is misleading, "/usr/lib/crt1.o".  You don't compile the libc magic bits.
I'm guessing from the context you're not aware of what PIC is.

I suggest opening a PR against the port in question.


----------



## leebrown66 (Feb 5, 2016)

That's a linker error on a dependent port (trousers).  I'd try a 'clean' then fresh rebuild of apache24 and all it's dependents, assuming you've not already done so.  I've seen this before and although I don't remember the circumstances, I'd hazard a guess that something made trousers build in an unusual way.
Sorry I'm not familiar enough with portmaster to suggest the right set of flags.


----------



## rtwingfield (Feb 5, 2016)

marino@ said:


> You don't.  That's not an error you should get, so there's a problem with the port.
> 
> also, the error message is misleading, "/usr/lib/crt1.o".  You don't compile the libc magic bits.
> I'm guessing from the context you're not aware of what PIC is.


Yes . .  .by the way, I did notice that the error diagnostics referred to *.o objects, specifically, "collect2: error: ld returned 1 exit status".  Actually I am reasonably knowledgeble of the process having _blundered_   into the esoteric world of Unix and C programming back in the late 1980's.  BTW, this is an excellent read (for interested readers) of the _compile_ process:  https://courses.cs.washington.edu/courses/cse378/97au/help/compilation.html  . . .and I'll add that I tend to refer to the whole process of preprocess, compile, assemble, and link, collectively as "_compiling_".  (I actually started my programmer career in an IBM OS360 shop, punching COBOL code onto hollerith cards using an 029 card punch machine, and finally dumping them into a card reader to _compile_ the program.)

Also, I would appreciate clarification of what PIC is or implies  



leebrown66 said:


> That's a linker error on a dependent port (trousers).  I'd try a 'clean' then fresh rebuild of apache24 and all it's dependents, assuming you've not already done so.  I've seen this before and although I don't remember the circumstances, I'd hazard a guess that something made trousers build in an unusual way.


Yes, following a successful isolated `portmaster /usr/ports/security/trousers`, I did re-do Apache24 and it did install as advertised.




leebrown66 said:


> Sorry I'm not familiar enough with portmaster to suggest the right set of flags.


What I have discovered by experimenting with `portmaster trousers` is that 
	
	



```
USE_GCC=any
```
 included in /etc/make.conf will override portmaster from default use of Clang and use the GCC.  To my chagrin, using the GCC results in the error; Trousers _compiles_ and links  successfully when using Clang.  I have repeated and reproduced this process.



marino@ said:


> I suggest opening a PR against the port in question.


  Do you think this should be reported . . .regarding the use of GCC?

Finally, I want to thank both of you gentlemen for your suggestion and help.


----------



## marino (Feb 5, 2016)

```
USE_GCC=any
```

Now there's a recipe for impeding disaster if I've ever seen one.


----------



## rtwingfield (Feb 5, 2016)

marino@ said:


> ```
> USE_GCC=any
> ```
> 
> Now there's a recipe for impeding disaster if I've ever seen one.



OK, so we'll just skip reporting this one.


----------



## leebrown66 (Feb 5, 2016)

PIC = Position Independent Code, which I'll assume you are familiar with if you understand the linker phase.  Typically required for shared libs, although I called it 'good form' when writing assembler back in the day.


----------



## rtwingfield (Feb 5, 2016)

leebrown66 said:


> PIC = Position Independent Code


 . . .well _duh_ of course, I'm not really a strong macro assembler coder; probably last time twenty five years ago on a Zenith Z-90 CPM box, and then mostly educational.  My C programming experience was mostly conducted on a NCR Motorola 68000 machine running AT&T Unix SVR3, so please excuse my lapse of memory (an associate just bought a T-shirt for me, "_I haven't lost my mind; it's backed up on the server . . .and the network is down_").

BTW, for anyone interested, here is a good read on PIC (even mentions my Motorola 68000).


----------



## leebrown66 (Feb 6, 2016)

Hah, CP/M was my first paid job before I left school.  I loved the 68k series CPU's, absolutely beautiful architecture, but unfortunately intel took over the world.  I despised the 8086, liked the 386 'cos finally there was kernel/user mode, then cried when I saw the 486 (no longer could a human optimize that encyclopedia of instructions).

68k's are still used today in the few PLC's  which I am fortunate enough to program occasionally in their strange ladder-logic.  Sad though that I can't code directly for the CPU, and as all the vendors add their own stuff onto the standard ladder logic, nothing is portable anyway.

I gotta get me that T-shirt!


----------

