pd-zexy compilation improvements

[IOhannes m zmoelnig]

On 2010-08-22 20:06, Jonas Smedegaard wrote:
> 
> Indeed this looks weird.  If you consider it sane to use this approach
> then I guess it won't matter much.  But striving towards the ultimate,
> if this is a dirty hack then please elaborate on possible alternative
> approaches - even if tricky to achieve: others here might have ideas on
> how to reach a higher level of elegantry (or however that word is bent).
> 

it's certainly in sync with the current puredata package in debian; the
relevant patches (using the pd_linux extension for debian/hurd and
debian/kFreeBSD) have even made it into upstream of puredata....

other pkgs usually use ".so" as extension, which Pd for historical
reasons does not, and instead uses it's own extension (varying across
platforms).

>> on other platforms (not x86 and x86_64) the flags should be no problems
>> (since they are not used)
> 
> This is bad! - i.e. I Am The Policy Police ;-)
>

somehow i expected this :-)

> We should not wait until someone gets hurt by pd-sexy not working on
> e.g. VIA boards *and* figure out the cause of the problem *and* file a
> bugreport about it.
> 
> We should simply suppress the sse flag on 32bit x86, in my opinion.

no problem.

> 
> I notice that upstream intend to switch to autotools for next release. 
> Perhaps you could convince upstream to add an option to add e.g. a
> --no-optimize or --no-buildtime-featuredetect flag so we can ensure
> compatibility generally for the archs we target - or if not too much to
> ask then above described runtime detection?

btw, upstream already uses a autoconf (with loads of m4 hacks...); the
intention is to switch to automake as well and get rid of the tweaks...

>>> Also, some archs have problems with fPIC, and I believe it is
>>> mentioned in Debian Policy that normal builds should *not* use fPIC
>>> while static libraries (unused here, just mentioning for completenes
>>> sake) *should* use it.
>>>
>>
>> the fPIC flag is tested for during configure time, and it's only used
>> if the compiler supports it.
>> it was introduced, because x86_64 does require it.
>> it can be turned off by using "--disable-PIC", though of course this
>> has to exclude x86_64
> 
> Do others have more knowledge about this than me?

this sounds a bit ironic, but i miss the smiley, so i guess it's not.

> 
> I suspect that it is not enough to simply test if -fPIC flag works -
> that it is more complicated than that, and more of a "Debian has decided
> to do it like this" rather than "this technically will certainly fail".
> 

i can only say that i know that all externals will fail to link on
x86_64 if the -fPIC flag is not present.

anyhow, i had a look at the debian policy, and it says (in chapter 10.2
Libraries on todays http://www.debian.org/doc/debian-policy/ch-files.html):
"If the package is architecture: any, then the shared library
compilation and linking flags must have -fPIC, or the package shall not
build on some of the supported architectures".

this seems to be exactly the opposite of what you suggest, as shared
libraries (and modules that are meant to be dlopen()ed _are_ shared
libraries) MUST have the "-fPIC" present.

i prefer if the build system tests, whether the compiler actually
accepts "-fPIC", just in case somebody uses an exotic compiler.


fmhsd
IOhannes










-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3636 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-multimedia-maintainers/attachments/20100823/4c279cb5/attachment.bin>