public inbox for gentoo-user@lists.gentoo.org
 help / color / mirror / Atom feed
From: Mike Edenfield <kutulu@kutulu.org>
To: gentoo-user@lists.gentoo.org
Subject: Re: [gentoo-user] installation aborted due to poor programming 	practices
Date: Mon, 19 Apr 2010 10:39:37 -0400	[thread overview]
Message-ID: <4BCC6B29.4010700@kutulu.org> (raw)
In-Reply-To: <j2qfecdbac61004190719oebb67ddbqbe9b89ea37db02fe@mail.gmail.com>

On 4/19/2010 10:19 AM, Arttu V. wrote:
> On 4/19/10, Helmut Jarausch <jarausch@igpm.rwth-aachen.de> wrote:
>> On 19 Apr, Neil Bothwick wrote:
>>> On Mon, 19 Apr 2010 12:47:17 +0200 (CEST), Helmut Jarausch wrote:
>>>
>>>> the installation of a package (unofficial gimp-gap) is 'aborted due to
>>>> poor programming practices' probably since there have been lots of
>>>> dereferencing type-punned pointers and similar warnings.
>>>>
>>>> How can I forced portage to install it anyway?
>>>
>>> Possibly FEATURES="-strict" emerge --opts blah
>>>
>>
>> Unfortunately this didn't help.
> 
> I wonder if strict and stricter FEATURES are somehow hardwired to each
> other inside portage code, or whether they're considered separate
> entities?
> 
> Anyway, you could try FEATURES="-strict -stricter" to see which way it
> works. If that won't work then the next step could be to play around
> with the QA_STRICT_* variables mentioned in make.conf man page
> (haven't tried, so don't know if they'll help either).
> 

The code that's causing the abort doesn't seem to have any options,
features, conditions, etc. that you can use to disable it.  If it finds
any misused type pointers, and you're on a 64-bit arch, it aborts.

Note that the errors it's checking for aren't your normal sloppy pointer
usages.  It's specifically looking for functions that are implicitly
declared as returning int, then later used as if they returned (void *).
 That kind of thing can only happen if the developer just flat out
forgot to include the prototypes ("poor programming practice" doesn't
even come close) and are almost guaranteed to cause something to crash
eventually on a 64-bit arch.

The only thing I can see that may let you install this overtop of
portage's complaints is to unset PORTAGE_LOG_FILE so the gcc warnings
have nowhere to go and portage won't find them.

See also: http://bugs.gentoo.org/40023



  reply	other threads:[~2010-04-19 15:04 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-04-19 10:47 [gentoo-user] installation aborted due to poor programming practices Helmut Jarausch
2010-04-19 10:59 ` Neil Bothwick
2010-04-19 12:55   ` Helmut Jarausch
2010-04-19 14:19     ` Arttu V.
2010-04-19 14:39       ` Mike Edenfield [this message]
     [not found] <eAWIa-2Oh-21@gated-at.bofh.it>
     [not found] ` <eAX1w-3Ad-17@gated-at.bofh.it>
     [not found]   ` <eAYJZ-6ob-31@gated-at.bofh.it>
2010-04-19 14:48     ` David W Noon

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4BCC6B29.4010700@kutulu.org \
    --to=kutulu@kutulu.org \
    --cc=gentoo-user@lists.gentoo.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox