[PD-dev] removing files from externals/build/src

[Hans-Christoph Steiner]

First off, thanks for the bug report.

On Dec 7, 2005, at 11:11 PM, ix wrote:

>> ...
>
> as for the deleting, feel free since you created the files in the
> first place, but keep in mind it will break the completeness of the
> SCons option if you start removing files...i prefer SCons since it is
> also used for building devel and actually works for me (see below)

I am not aiming to break things, I am trying to build as much as  
possible.  What is in externals/build/src is only part of what is in  
externals/.  But I am fine with leaving the files in  
externals/build/src in place, the only ones that need to be removed are  
the ones with name clashes, like change, prepend, average, scale, etc.   
They prevent access to the objects of the same name using the namespace  
(they'd always be found first in the path).

>> But now there is something better.
>
> ok... bug report then.. :)
>
> (first try)
>
> externals # make
> Makefile:24: /usr/src/pd/externals/../packages/Makefile.buildlayout:
> No such file or directory
> make: *** No rule to make target
> `/usr/src/pd/externals/../packages/Makefile.buildlayout'.  Stop.
> :
>
> fix: checkout "packages" - since this is a seperate module, perhaps
> the dep can be moved over since im guessing about 15% of users at most
> checkout "."..esp with all the weird stuff in it like framestein DLLs
> and PHP pages

If its a problem, a copy of Makefile.buildlayout can easily be added to  
the base of externals.  I had it there originally, but then removed it  
since I was changing it a fair amount and it was a pain to keep them in  
sync.  It could even have different values that  
packages/Makefile.buildlayout if that would helpful.  When the other  
Makefiles are called from packages/Makefile, they are redirected to  
packages/Makefile anyhow.

This is the layout that I assume in building this:
http://puredata.org/docs/developer/devlayout

> (second try)
>
> gcc   -Wl,-export_dynamic  -shared -o
> "/usr/src/pd/externals/../externals/cxc/ENV.pd_linux"
> "/usr/src/pd/externals/../externals/cxc/ENV.o" -lc -lm
> /usr/lib/gcc/x86_64-pc-linux-gnu/4.1.0-beta20051125/../../../../ 
> x86_64-pc-linux-gnu/bin/ld:
> /usr/src/pd/externals/../externals/cxc/ENV.o: relocation R_X86_64_32
> against `a local symbol' can not be used when making a shared object;
> recompile with -fPIC
> /usr/src/pd/externals/../externals/cxc/ENV.o: could not read symbols:  
> Bad value
> collect2: ld returned 1 exit status
>
> fix: add -fPIC to CFLAGS in /externals/makefile

Oops, -fPIC was there, but this exposed another bug.  I wonder why it  
was compiling fine for me on Linux...

> (third try)

> it finished...ok. 'make install' wait...why is it configuring more
> stuff?!?!?! this should have been done in the make step.

I fixed these two problems. Its a work in progress.  When you look into  
the structure of all the code in externals, you'll see that its is far  
from clean.  There are a number of hacky workarounds in  
externals/Makefile for sure.

> /usr/lib/gcc/x86_64-pc-linux-gnu/4.1.0-beta20051125/../../../../ 
> x86_64-pc-linux-gnu/bin/ld:
> sendOSC.o: relocation R_X86_64_32 against `a local symbol' can not be
> used when making a shared object; recompile with -fPIC
> sendOSC.o: could not read symbols: Bad value
> collect2: ld returned 1 exit status
>
> fix: uh.. i guess go around to all these other makefiles and add -fPIC
> since it didnt properly inherit the one in /externals/makefile. imo
> this is the biggest advantage to the SCons system where you have a
> parent environment, set the flags once, and you _know_ all the
> subprojects are going to get the same flags and binary/doc location,
> since they dont even have their own makefiles.

This is also possible and preferred with Makefiles, I tried to take  
advantage of this as much as possible in the work I just did.  Its just  
that there are a lot of legacy Makefiles around, and many of them don't  
conform to the Makefile standards.  OSCx is not a straightforward  
build, so I haven't really messed with it at all.  It would be nice if  
it worked on MinGW too.

>
> also, i noticed after various -fPIC failures, it kept going. is it
> logging these somewhere?

This is a byproduct of calling another build system from the command  
line (i.e. cd blah/blah && make).  It would work properly if it was  
part of the same Makefile.

> (try four)
>
> /bin/sh: /usr/src/pd/externals/../scripts/generate-libdir-metafile.sh:
> No such file or directory
>
> fix: checkout "scripts" (see try one)
>
> (try five)
>
> more -fPIC stuff...only 'make clean' is not deleting .o files in the
> subprojects compiled without -fPIC, so i give up for now, to lazy to
> do some find . -iregex '.*.o' -exec rm {} \; ;)

Again a byproduct of using existing Makefiles.  The stuff I have  
recently written all cleans up more or less properly after itself.

> .c....sure, 6 thru 10 once we get these figured out, im happy to try  
> again...

Please try again :)

.hc

________________________________________________________________________ 
____

News is what people want to keep hidden and everything else is  
publicity.
                                                                          
                      - Bill Moyers