[PD-dev] [LONG] Building extended on amd64

[Hans-Christoph Steiner]

On Oct 2, 2009, at 1:06 PM, András Murányi wrote:

>
>
> 2009/10/2 Hans-Christoph Steiner <hans at at.or.at>
>
> On Oct 1, 2009, at 7:34 PM, András Murányi wrote:
>
>>
>>
>> 2009/10/1 IOhannes m zmoelnig <zmoelnig at iem.at>
>> András Murányi wrote:
>> > Thanks! Without root i'm still getting those access denied  
>> errors, as root
>>
>>
>> most likely because you checked out as root, which results in files
>> being owned by root and not you.
>> simple fix is:
>> % cd /home/muranyia/Download/0.41/
>> % chown -R muranyia .
>>
>> imho, you should do this before anything else and then continue to  
>> work
>> as user.
>>
>>
>> I didn't check out as root but it seems a previous 'sudo make  
>> install' messed up the build directory. Chown didn't help, so i  
>> deleted the whole source and checked it out again - problem gone.
>
>
> Never run any builds as root, its a good way to mess things up.  :)
>
>
> Of course we don't. Only if things don't work, and the target is  
> called 'install', we might have the false impression that we need  
> root.
>
>>
>> > it goes as far as this:
>> >
>> > gcc -o ../bin/accum.pd_linux -Wall -W -Wstrict-prototypes -Wno- 
>> unused
>> >> -Wno-parentheses -Wno-switch -O2 -funroll-loops -fomit-frame- 
>> pointer -DUNIX
>> >> -I . -I ../../../pd/src -I ../shared -export_dynamic  -shared  
>> hammer/accum.o
>> >>
>> >> /usr/bin/ld: hammer/accum.o: relocation R_X86_64_32 against `a  
>> local
>> >> symbol' can not be used when making a shared object; recompile  
>> with -fPIC
>> >> hammer/accum.o: could not read symbols: Bad value
>>
>> like the others and the error message have said: recompile with - 
>> fPIC.
>> you will have to clean the build first (make clean), in order to make
>> the added "-fPIC" copiler flag have any affect on the created  
>> object files.
>>
>>
>> Make clean got into and endless loop, had to delete source again :o/
>>
>> I also took a look at this doc:
>> http://support.amd.com/us/Processor_TechDocs/32035.pdf
>> ...and decided to add this to the Makefile:
>
>
> Which Makefile?  It should be 0.41/packages/linux_make/Makefile
>
> Yes
>
>
> When you run 'uname -m'  what does it tell you?
>
> x86_64. I also tried it without if/endif, cyclone still ignored it.


Try sticking it directly in externals/miXed/Makefile.common.

.hc




>
>> # AMD64
>> ifeq ($(TARGET_PLATFORM),x86_64)
>> OPT_CFLAGS += -march=k8 -fPIC
>> OPT_CFLAGS += -O3 -ffast-math
>> endif
>>
>> ...which concluded at this:
>>
>> make[3]: Entering directory `/home/muranyia/Download/0.41/externals/ 
>> miXed/cyclone'
>> gcc -Wall -W -Wstrict-prototypes -Wno-unused -Wno-parentheses -Wno- 
>> switch -O2 -funroll-loops -fomit-frame-pointer -DUNIX -I . - 
>> I ../../../pd/src -I ../shared   -c -o hammer/accum.o hammer/accum.c
>> gcc -o ../bin/accum.pd_linux -Wall -W -Wstrict-prototypes -Wno- 
>> unused -Wno-parentheses -Wno-switch -O2 -funroll-loops -fomit-frame- 
>> pointer -DUNIX -I . -I ../../../pd/src -I ../shared - 
>> export_dynamic  -shared hammer/accum.o
>> /usr/bin/ld: hammer/accum.o: relocation R_X86_64_32 against `a  
>> local symbol' can not be used when making a shared object;  
>> recompile with -fPIC
>> hammer/accum.o: could not read symbols: Bad value
>> collect2: ld returned 1 exit status
>> make[3]: *** [../bin/accum.pd_linux] Error 1
>> make[3]: Leaving directory `/home/muranyia/Download/0.41/externals/ 
>> miXed/cyclone'
>> make[2]: *** [cyclone] Error 2
>> make[2]: Leaving directory `/home/muranyia/Download/0.41/externals'
>> make[1]: *** [externals_install] Error 2
>> make[1]: Leaving directory `/home/muranyia/Download/0.41/packages'
>> make: *** [install] Error 2
>>
>> Sadly i don't have the skills to dive into this by myself, so again  
>> i'm hoping for your advice.
>
> For whatever reason, the OPT_FLAGS didn't get set for cyclone again,  
> since its the same error.  Let's find that reason (see above  
> questions).
>
> .hc
>
>
> Thanks! Andras
>
>



----------------------------------------------------------------------------

"Making boring techno music is really easy with modern tools," he
says, "but with live coding, boring techno is much harder." - Chris  
McCormick




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-dev/attachments/20091003/6fd42306/attachment.htm>