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