Copying the original msg below, since I forgot to cc the list.

Making gcc45 and libffi conflict would seem exagerated to me _
all pkgs that bdep on libffi would block if a user has gcc45
installed, and the user would first have to manually remove
gcc45 _ and restore it manually after..
For what seems to me trying to avoid a risk of which I can't even
see an example _ and of which we've never seen an example with
previous gcc4x . Even if there were some pkg for which it is important
to link against this or that version of libffi,
the pkg should take care of it.

I'd suggest just use update-alternatives...

Best,

Jean-Francois

On 15 Apr 2010, at 15:11, Jack Howarth wrote:

> On Thu, Apr 15, 2010 at 05:53:57AM +0200, Jean-François Mertens wrote:
>>
>> On 14 Apr 2010, at 21:53, Jack Howarth wrote:
>>
>>> I have updated the gcc45 packaging to 4.5.0-1000
>>> since gcc 4.5.0 was released today. I've not tested
>>> the packaging yet but here should be no issues left
>>> other than the conflict with libffi. It is unclear
>>> to me what the proper fix is for that (ie who should
>>> own the manpage for ffi).
>>>       Jack
>>
>>
>> Hi Jack,
>>
>> I just updated libffi to check on that;
>> I guess the same conflict will remain,
>> so _ either the 2 manpages are essentiially equivalent,
>> ad then a mutual "Replaces" would suffice,
>> or else update-alternatives is called for,
>> and then (if that's what you mean with "who should own"),
>> it seems clear, as a matter of general principle,
>> that the original pkg has the higher priority...
>> Since libffi belongs to "None", you can handle this
>> for both pkgs.
>
> Jean-Francois,
>    My own inclination was to Conflict the gcc45 and libffi
> package (less in order to solve the ffi.3 issue but to make
> sure that gcc45 always linked things against its own copy
> of libffi).
>    I have been tinkering with the idea of creating a set
> of gcc4x-dev packages so that the different gcc4x compiler
> packages could co-exist. However I'm not certain how
> complex that would be to layer on top of the existing
> installed gcc4x packages.
>        Jack
> ps I mention the second issue because one could then just
> conflict gcc45-dev and libffi (which in the first case would
> just deinstall a set of symlinks). There have been some users
> who have requested the ability to have gcc43 and gcc44 co-existing
> in a usable form.
>
>>
>> But in the meantime I get (on 10.5 32bit _ on the 64bit side it
>> continues happily..:
>> binutils didn't build there..)
>>
>>> checking linker --sysroot support... no
>>> checking __stack_chk_fail in target C library... checking for
>>> __stack_chk_fail... yes
>>> yes
>>> Using ggc-page for garbage collection.
>>> checking whether to enable maintainer-specific portions of
>>> Makefiles... no
>>> Links are now set up to build a native compiler for i386-apple-
>>> darwin9.8.0.
>>> checking for exported symbols... unable to read unknown load command
>>> 0x1b
>>> /sw/bin/objdump: conftest: Invalid operation
>>> checking for -rdynamic... unable to read unknown load command 0x1b
>>> /sw/bin/objdump: conftest: Invalid operation
>>> checking for library containing dlopen... none required
>>> checking for -fPIC -shared... yes
>>> configure: error:
>>> Building GCC with plugin support requires a host that supports
>>> -fPIC, -shared, -ldl and -rdynamic.
>>> make[2]: *** [configure-stage1-gcc] Error 1
>>> make[1]: *** [stage1-bubble] Error 2
>>
>> with :
>>
>> # dlocate -S /sw/bin/objdump
>> binutils: /sw/bin/objdump
>>
>> gcc seems too unwilling to cooperate with other pkgs
>> _ i.e., use "system-.." _ (even for gettext if I remember well !)
>>
>> Cheers,
>>
>> Jean-Francois


------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
http://news.gmane.org/gmane.os.apple.fink.devel
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-devel

Reply via email to