pd-zexy compilation improvements

[Jonas Smedegaard]

On Mon, Aug 23, 2010 at 09:25:12AM +0200, IOhannes m zmoelnig wrote:
>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).

Hmm. Do we then perhaps need to beware of this for helper tools like 
lintian and dh_shlibdeps?

I actually do not think that dh_shlibdeps has any role here, just 
mentioning it as an example: For Debian packaging we have a bunch of 
helper tools used either directly during packaging or during various 
tests and inspections, which rely on e.g. shared libraries ending in .so 
and located below /usr/lib.  When then unusual things are done, we might 
want to add hints for such tools to not hide potential problems from 
them.

Or expressed differently: Even if PureData works splendid with its 
unusual naming, we still might benefit in Debian (and derivatives) from 
using the classic .so extension if indeed it is technically the same.


One example issue we could be hiding is that of rpath usage: Everything 
works fine but Debian set higher standards than "works fine for *normal* 
use" and lintian checks was added at some point to warn if rpath was 
used in shared libraries.

Again, I do not say that rpath in particular is my concern - it is but 
an example: Could be some other similarly "pedantic" issue raised later, 
which none of us today know about, but will remain hidden if we use odd 
naming for a common file type.


>>>> 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.

It is not: I know Make, Perl, Bash, love regular expressions, and can 
juggle patches. But cannot do a helloworld in C or C++.

It takes more than a smiley to change that :-)



NB! Please do not cc me - I am subscribed, and it messes up my MUA.


  - Jonas

-- 
  * Jonas Smedegaard - idealist & Internet-arkitekt
  * Tlf.: +45 40843136  Website: http://dr.jones.dk/

  [x] quote me freely  [ ] ask before reusing  [ ] keep private
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-multimedia-maintainers/attachments/20100824/cd7b6282/attachment-0001.pgp>