Bug 390261 – www-plugins/nspluginwrapper-1.4.4-r1 - In file included from .../work/nspluginwrapper-1.4.4/src/utils.c:29:0: /usr/include/dirent.h:42:19: error: conflicting types for 'ino64_t'

• Status: RESOLVED WORKSFORME
• Product: Gentoo Linux

[Description Sven Czarnian 2011-11-12 14:33:03 UTC]

I tried to build ndiswrapper, but gcc does not compile the code. it detects problems with ino64_t.
The different logs are attached to the bug-report.

Reproducible: Always

Steps to Reproduce:
1. emerge -qavj adobe-flash
2.
3.
Actual Results:  
The emerge fails

Expected Results:  
The emerge finishes

[Comment 1 Sven Czarnian 2011-11-12 14:34:01 UTC]

Created attachment 292285 [details]
The build.log of nspluginwrapper-1.4.4-r1

[Comment 2 Sven Czarnian 2011-11-12 14:35:20 UTC]

Created attachment 292287 [details]
The output of emerge --info

[Comment 3 Agostino Sarubbo 2011-11-12 15:39:14 UTC]

can you attach a build log compiled with LC_ALL=C ?

[Comment 4 Sven Czarnian 2011-11-12 15:49:15 UTC]

Created attachment 292293 [details]
build.log with LC_ALL=C

[Comment 5 Sven Czarnian 2011-11-12 15:49:41 UTC]

Added the build log.

[Comment 6 Patrick McLean 2012-04-16 03:49:58 UTC]

Is this still happening? Could you post the output of emerge --info

[Comment 7 David Mainzer 2012-06-12 11:55:34 UTC]

Created attachment 315091 [details]
emerge --info =www-plugins/nspluginwrapper-1.4.4-r3

[Comment 8 David Mainzer 2012-06-12 11:57:13 UTC]

Today it tried to update nspluginwrapper from 1.4.4-r1 to 1.4.4-r3 but i got the same error ... i attached the build log and emerge --info

[Comment 9 David Mainzer 2012-06-12 11:58:52 UTC]

Created attachment 315093 [details]
Build.log

[Comment 10 F. Fischer 2012-08-11 07:17:55 UTC]

Created attachment 320970 [details]
emerge --info

I get the same error now with every revisions of www-plugins/nspluginwrapper-1.4.4

my last succesful build according to qlop: 
Thu Sep 22 00:25:40 2011 >>> sys-libs/glibc-2.12.2
Thu Sep 22 22:44:42 2011 >>> www-plugins/nspluginwrapper-1.4.4-r1

[Comment 11 Pacho Ramos 2016-01-26 10:58:31 UTC]

As explained here:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=686029
https://bugzilla.redhat.com/show_bug.cgi?id=1289053

Maybe we should finally treeclean this package as all browsers are going away from npapi plugins and the old flash plugin (used in firefox) has native amd64 support

[Comment 12 Pacho Ramos 2016-06-16 17:22:33 UTC]

(In reply to Pacho Ramos from comment #11)
> As explained here:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=686029
> https://bugzilla.redhat.com/show_bug.cgi?id=1289053
> 
> Maybe we should finally treeclean this package as all browsers are going
> away from npapi plugins and the old flash plugin (used in firefox) has
> native amd64 support

CCing adobe-flash maintainers as the ebuild would need to be adapted

[Comment 13 Jeroen Roovers (RETIRED) 2016-06-21 07:00:13 UTC]

(In reply to Pacho Ramos from comment #11)
> As explained here:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=686029
> https://bugzilla.redhat.com/show_bug.cgi?id=1289053
> 
> Maybe we should finally treeclean this package as all browsers are going
> away from npapi plugins and the old flash plugin (used in firefox) has
> native amd64 support

The issue was last confirmed in 2012 and no duplicates were filed. Several maintainers changed the ebuilds and the eclasses it uses have changed as well over the years (notably multilib.eclass).

I can't reproduce it now. Newer versions went stable since this issue was filed. We don't even know yet what caused the issue in these two instances.