Re: gcc-4.3.0 and -fPIC flags fails?

["Franzi Edo." <edo dot franzi at ukos dot ch>]

Hi Brian,
I have tried to use the -fPIC flag not only for the compiling phase,  
but also for the linking one.
Unsuccessfully.
The target I use is the cpu32 (m68k). The previous gcc release (4.2.3)  
works fine with the same
makefile. You have mentioned that I have to build the libgcc with  
the .fPIC flag... Do I have to
specify this during the construction of the toolchain or during the  
normal program linking phase?
Do you have any examples? Here is part of my makefike:
Thanks, Edo

GCC_VERSION	= 4.2.3
CPU				= m68k-elf
BOARD			= Andras_68k
CORE			= MC68332
COMMUNS_PATH	= ../../../Communs/$(BOARD)
LIBKERN_PATH	= ../../../Int_kern
LIBCOMM_PATH	= ../../../Int_comm
LIBGENE_PATH	= ../../../Int_gene
LIBTBOX_PATH	= ../../../Int_tbox
GCC_PATH		= /Users/Shared/cross/gcc-$(GCC_VERSION)/$(CPU)/bin

CC				= $(GCC_PATH)/$(CPU)-gcc
LD				= $(GCC_PATH)/$(CPU)-ld
OBJDUMP		= $(GCC_PATH)/$(CPU)-objdump
OBJCOPY		= $(GCC_PATH)/$(CPU)-objcopy
CC_FLAGS		= -mcpu32 -Wall -g -O3
LD_FILE			= ../../../Includes/$(BOARD)/link_sys.ld

LD_FLAGS		= -mcpu32 -nostartfiles -Wl,-T$(LD_FILE),-Map,$(TARGET).map
OBJDUMP_FLAGS	= -d -h -t -S -s

DEP 			= ../../../Includes/uKOS.h \
 				  ../../../Includes/ip.h \
				  ../../../Includes/structures.h \
	  			  ../../../Includes/structures.s \
 				  ../../../Includes/uKOS_types.h \
				  ../../../Includes/$(BOARD)/calls.h \
	  			  ../../../Includes/$(BOARD)/cpu_reg.h \
	  			  ../../../Includes/$(BOARD)/cpu_reg.s \
				  ../../../Includes/$(BOARD)/vectors.h \
	  			  ../../../Includes/$(BOARD)/link_sys.ld \
	  			  ../../../Includes/$(BOARD)/mapping.h \
	  			  ../../../Includes/$(BOARD)/mapping.s \
				  ../../../Int_comm/lib_comm.h \
				  ../../../Int_gene/lib_gene.h \
				  ../../../Int_kern/lib_kern.h \
				  ../../../Int_tbox/lib_tbox.h \
				  ../../../Lib_comm/comm/comm.h \
				  ../../../Lib_comm/sci0/sci0.h \
				  ../../../Lib_gene/iotx/iotx.h \
				  ../../../Lib_gene/syos/syos.h \
				  ../../../Lib_gene/text/text.h \
				  ../../../Lib_kern/kern/conf.h \
				  ../../../Lib_kern/kern/kern.h \
				  ../../../Lib_kern/kern/asso.h \
				  ../../../Lib_kern/kern/sema.h \
				  ../../../Lib_kern/kern/mbox.h \
				  ../../../Lib_kern/kern/desc.h \
				  ../../../Lib_kern/kern/list.h \
				  ../../../Lib_tbox/strg/strg.h \
				  ../../../Lib_tbox/misc/misc.h \
				  ../../../Lib_tbox/i2c0/i2c0.h \
				  ../../../Lib_tbox/glob/glob.h \
				  ../../../Lib_tbox/bus1/bus1.h \
				  ../../../Lib_tbox/bus0/bus0.h \
	  			  makefile

all :
	make -f ./makefile TARGET=process app

clean :
	rm -f *.elf *.lst *.o *.map

clean_p :
	rm -f *.elf *.lst *.o *.map

clean_all :
	rm -f *.elf *.lst *.o *.map *.bin

app : $(TARGET).lst $(TARGET).bin $(TARGET).elf

$(TARGET).elf : header.o start.o $(TARGET).o $(LD_FILE) $(DEP) makefile
	$(CC) -fPIC $(LD_FLAGS) \
	header.o \
	start.o \
	$(TARGET).o \
	$(LIBCOMM_PATH)/lib_comm.a \
	$(LIBGENE_PATH)/lib_gene.a \
	$(LIBKERN_PATH)/lib_kern.a \
	$(LIBTBOX_PATH)/lib_tbox.a \
	 -o $@

%.o : %.s $(DEP) makefile
	$(CC) -c $(CC_FLAGS) $<

%.o : %.c $(DEP) makefile
	$(CC) -msep-data -fPIC -c $(CC_FLAGS) $<

%.o : ../%.c $(DEP) makefile
	$(CC) -msep-data -fPIC -c $(CC_FLAGS) $<

%.lst : %.elf $(DEP) makefile
	$(OBJDUMP) $(OBJDUMP_FLAGS) $< > $@

%.bin : %.elf $(DEP) makefile
	$(OBJCOPY) -O binary --strip-all $< $@


On 23 Mar, 2008, at 18:35, Brian Dessent wrote:
> "Franzi Edo." wrote:
>
> > Unfortunately, the analysis of the routine __fixunssfsi, shows that  
> > some
> > absolute calls remains (a couple of jsr !!!!). In the previous  
> > version
> > of gcc (4.2.3)
>
> Are you linking with static or shared libgcc?  That function is in
> libgcc and if you link to a libgcc that wasn't built PIC then it  
> follows
> that it will have absolute addressing.
>
> What target is this?  If you want you can probably change the multilib
> options to specify that libgcc should be built -fPIC when static.  It
> looks like OpenBSD does this already, see config/m68k/t-*.
>
> Brian


--
For unsubscribe information see http://sourceware.org/lists.html#faq