Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 167939 - net-libs/wvstreams-4.2.2-r3 fails to emerge with gcc-4.1.2
Summary: net-libs/wvstreams-4.2.2-r3 fails to emerge with gcc-4.1.2
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: [OLD] Library (show other bugs)
Hardware: All Linux
: High normal (vote)
Assignee: Alin Năstac (RETIRED)
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2007-02-22 00:25 UTC by Martin Väth
Modified: 2007-07-02 21:06 UTC (History)
6 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
ebuild for wvstreams-4.3 (wvstreams-4.3.ebuild,2.33 KB, text/plain)
2007-03-09 10:32 UTC, Christoph Jacob
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Martin Väth 2007-02-22 00:25:51 UTC
Recently, wvstreams (neither 4.2.2-r2 nor 4.2.2-r3) does emerge/compile anymore. I am not sure which caused it on my system, but I think perhaps a stricter checking of the new gcc-4.1.2 might be the cause. Maybe this even is a gcc-4.1.2 bug, because the accused file wvvector.h looks correct IMHO (especially, I do not understand why gcc thinks that "link" is undeclared). These are the compiler error messages:

./include/wvvector.h: In member function 'T* WvVector<T>::Iter::ptr() const':
./include/wvvector.h:361: error: there are no arguments to 'cur' that depend on a template parameter, so a declaration of 'cur' must be available
./include/wvvector.h:361: error: (if you use '-fpermissive', G++ will accept your code, but allowing the use of an undeclared name is deprecated)
./include/wvvector.h: In member function 'bool WvVector<T>::Iter::get_autofree() const':
./include/wvvector.h:371: error: 'link' was not declared in this scope
./include/wvvector.h: In member function 'void WvVector<T>::Iter::set_autofree(bool)':
./include/wvvector.h:379: error: 'link' was not declared in this scope
./include/wvvector.h: In member function 'void WvVector<T>::Iter::remove(bool)':
./include/wvvector.h:389: error: 'i' was not declared in this scope
./include/wvvector.h: In member function 'void WvVector<T>::Iter::xremove(bool)':
./include/wvvector.h:407: error: 'i' was not declared in this scope
./include/wvvector.h:408: error: there are no arguments to 'prev' that depend on a template parameter, so a declaration of 'prev' must be available



Reproducible: Always

Steps to Reproduce:




Portage 2.1.2-r9 (default-linux/x86/2006.1/desktop, gcc-4.1.2, glibc-2.5-r0, 2.6.19-hardened-r6 i686)
=================================================================
System uname: 2.6.19-hardened-r6 i686 AMD Athlon(tm) 64 Processor 3000+
Gentoo Base System release 1.12.9
Timestamp of tree: Tue, 20 Feb 2007 13:20:01 +0000
ccache version 2.4 [enabled]
dev-java/java-config: 1.3.7, 2.0.31-r3
dev-lang/python:     2.4.3-r4
dev-python/pycrypto: 2.0.1-r5
dev-util/ccache:     2.4-r6
sys-apps/sandbox:    1.2.17
sys-devel/autoconf:  2.13, 2.61
sys-devel/automake:  1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2, 1.10
sys-devel/binutils:  2.17
sys-devel/gcc-config: 1.3.14
sys-devel/libtool:   1.5.22
virtual/os-headers:  2.6.19.2-r2
ACCEPT_KEYWORDS="x86"
AUTOCLEAN="yes"
CBUILD="i686-pc-linux-gnu"
CFLAGS="-march=pentium3m -O2 -fno-ident -pipe"
CHOST="i686-pc-linux-gnu"
CONFIG_PROTECT="/etc /usr/kde/3.5/env /usr/kde/3.5/share/config /usr/kde/3.5/shutdown /usr/share/X11/xkb /usr/share/config"
CONFIG_PROTECT_MASK="/etc/env.d /etc/env.d/java/ /etc/gconf /etc/java-config/vms/ /etc/revdep-rebuild /etc/terminfo /etc/texmf/web2c"
CXXFLAGS="-march=pentium3m -O2 -fno-ident -pipe"
DISTDIR="/gentoo64/distdir.mv/distfiles"
FEATURES="autoconfig buildpkg candy ccache collision-protect distlocks sandbox sfperms strict userfetch userpriv usersandbox"
GENTOO_MIRRORS="http://ftp.uni-erlangen.de/pub/mirrors/gentoo"
LINGUAS="en de ru"
PKGDIR="/space/gentoo/i686"
PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --delete-after --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages"
PORTAGE_TMPDIR="/var/tmp"
PORTDIR="/gentoo64/usr/portage"
PORTDIR_OVERLAY="/home/gentoo/various/portage"
SYNC="rsync://rsync.europe.gentoo.org/gentoo-portage"
USE="16bit 3dnow 3dnowext 64bit 7zip S3TC X a52 aac aalib ace acpi addbookmarks adplug adsl aiglx akode alsa amarok amr aoss aotuv arj arts asf async athena auctex audiofile ax25 bash-completion bcmath berkdb bigpatch binary-drivers binfilter bittorrent bl blas boost branding bzip2 cap caps capslib cardbus cblas ccache cdaudio cdda cdf cdparanoia cdr cdrom cdsound cg chasen checkpath chipcard chipcard2 clvm cmdsubmenu colordiff compress config_wizard connectionstatus contrarius cpio cran crypt css cups curl curlwrappers custom-cflags cvs dbus dcraw de_tvtoday demo device-mapper dga dio directfb discard-path divx dnd dnotify dolby-record-switch doomsday double-precision dri dtaus dts dv dvbplayer dvd dvdr dvdread dynamic dynamicplugin ecc emacs emf emovix encode ermt escreen esd eurofile exif extras fam fame fat fbcon fbsplash festival ffmpeg filter firefox fix-connected-rt flac fmod force-cgi-redirect force-reg fortran fortran95 ftp gcc-opts gd gdbm geldkarte gencertdaily gif gimp gimpprint ginac gkrellm glade glgd glibc-omitfp glitz glsa glut gmail gmedia gmp gmtsuppl gmttria gnet gnutella gpm grammar gre gs gsm gtk gtk2 gzip gzip-el hal hardenedphp hbci hddtemp hwmixer ibam iconv id3 idea ieee1394 ilbc image imagemagick imap imlib inquisitio ipfilter ipsec jack java java-external jbig jce jpeg jpeg2k jrtplib kde kdecards kdehiddenvisibility kmid lame latex lha libsamplerate libtommath lights live login-watch logitech-mouse logrotate long-double lzo lzw mad math matroska maya-shaderlibrary mbox md5sum memlimit midi mikmod mime mimencode mixer mjpeg mmx mmxext mng mod mode-force mode-paranoid modplug mods motif mounts-check mozbranding mozilla moznocompose moznoirc moznopango moznoxft mp3 mp3rtp mp4 mp4live mpeg mpeg2 mplayer mschap mtp mupad-noscilab musepack music nas nat ncurses new-reg-alloc nforce2 nls no-old-linux noamazon noantlr nobeanutils nocd nocommonslogging nodpkg noflagstrip nojdepend nojsch nojython nolog4j nolvm1 nolvmstatic nomirrors norhino nosnapshots nowin nptl nptlonly nvidia nvtv oci8-instant-client octave offensive office ogg ogre on-the-fly-crypt openal opendoc openexr opengl openstreetmap opera oss p2p pager patch pch pcmcia pcntl pcre perl pic player plib plotutils pmount png pop portaudio posix ppds preview-latex print projectx ps pygrub python qmax qt3 quicktime rar rc5 readline real realmedia realms recode reiser4 reiserfs remix replytolist restrict-javascript rle roe rogue rotor rtsp scanner scenarios screen sdl sdl-image sdlaudio seamonkey serpentine setup-plugin sid skins slang smime sndfile sofia-sip songdb sou sox speex spell srt sse sse2 ssl stats stlport stream streamripper submenu subtitles subversion suidcheck sysfs szip tabs tagwriting tcl tcltk tcpmd5 tetex textures themes theora thesaurus threads threadsafe thumbnail tiff timidity tk tomsfastmath toolkit-scroll-bars transcode truetype tta tv_check tv_pick_cgi twolame unicode unzip usb userfiles userlocales uudeview uuencode v4l v4l2 vcd videos visual visualization vlm voice vorbis vorbis-psy wavpack win32codecs wma wmf wmp wordperfect wxwindows x264 x86 xanim xatrix xchattext xcomposite xext xgetdefault xine xlockrc xorg xosd xplanet xpm xrandr xscreensaver xterm xv xvid xvmc yaepg yv12 zip zlib zrtp zvbi" ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem bt87x ca0106 cmipci emu10k1 emu10k1x ens1370 ens1371 es1938 es1968 fm801 hda-intel intel8x0 intel8x0m maestro3 trident usb-audio via82xx via82xx-modem ymfpci" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mulaw multi null plug rate route share shm softvol" ELIBC="glibc" INPUT_DEVICES="keyboard mouse" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LINGUAS="en de ru" USERLAND="GNU" VIDEO_CARDS="fbdev nv nvidia radeon v4l vesa vga"
Unset:  CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LANG, LC_ALL, LDFLAGS, MAKEOPTS, PORTAGE_RSYNC_EXTRA_OPTS
Comment 1 Martin Väth 2007-02-22 00:30:21 UTC
I should add that of course I tried also with -fpermissive in C*FLAGS: This turns the first error message into a warning, but the subsequent errors about the undeclared symbols remain.
Comment 2 Robin Bankhead 2007-02-22 10:02:45 UTC
Same here, and likewise only first error changed to warning with "-fpermissive".

pengi ~ # emerge --info
Portage 2.1.2-r10 (default-linux/x86/2006.1/desktop, gcc-4.1.2, glibc-2.5-r0, 2.6.20-gentoo i686)
=================================================================
System uname: 2.6.20-gentoo i686 Intel(R) Celeron(R) CPU 2.60GHz
Gentoo Base System release 1.12.9
Timestamp of tree: Wed, 21 Feb 2007 20:20:01 +0000
distcc 2.18.3 i686-pc-linux-gnu (protocols 1 and 2) (default port 3632) [enabled]
ccache version 2.4 [enabled]
dev-java/java-config: 1.3.7, 2.0.31-r3
dev-lang/python:     2.4.4
dev-python/pycrypto: 2.0.1-r5
dev-util/ccache:     2.4-r6
sys-apps/sandbox:    1.2.18.1
sys-devel/autoconf:  2.13, 2.61
sys-devel/automake:  1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2, 1.10
sys-devel/binutils:  2.17
sys-devel/gcc-config: 1.3.14
sys-devel/libtool:   1.5.23b
virtual/os-headers:  2.6.20
ACCEPT_KEYWORDS="x86 ~x86"
AUTOCLEAN="yes"
CBUILD="i686-pc-linux-gnu"
CFLAGS="-O2 -march=pentium4 -mmmx -msse -msse2 -fomit-frame-pointer -pipe -w"
CHOST="i686-pc-linux-gnu"
CONFIG_PROTECT="/etc /usr/bin/pptpconfig.php /usr/kde/3.5/env /usr/kde/3.5/share/config /usr/kde/3.5/shutdown /usr/share/X11/xkb /usr/share/config /usr/share/wine"
CONFIG_PROTECT_MASK="/etc/env.d /etc/env.d/java/ /etc/gconf /etc/java-config/vms/ /etc/revdep-rebuild /etc/terminfo /usr/share/wine/fonts"
CXXFLAGS="-O2 -march=pentium4 -mmmx -msse -msse2 -fomit-frame-pointer -pipe -w"
DISTDIR="/usr/portage/distfiles"
FEATURES="autoconfig ccache distcc distlocks metadata-transfer nodoc sandbox sfperms strict"
GENTOO_MIRRORS="http://gentoo.blueyonder.co.uk/"
LINGUAS="en_GB"
MAKEOPTS="-j7"
PKGDIR="/usr/portage/packages"
PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --delete-after --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages"
PORTAGE_TMPDIR="/var/tmp"
PORTDIR="/usr/portage"
PORTDIR_OVERLAY="/usr/local/portage"
SYNC="rsync://brazil/gentoo-portage"
USE="X a52 aac acpi aiglx alsa apache2 arts asf avi berkdb bitmap-fonts bluetooth bzip2 cairo cdparanoia cdr cli cracklib crypt cups dbus dio dri dvd dvdread eds emboss encode esd fam ffmpeg firefox flac flash foomaticdb fortran gdbm gif gimp glitz gpm gstreamer gtk2 hal i8x0 iconv ieee1394 imagemagick innodb isdnlog java javascript jpeg kde ldap libg++ libwww mad matroska midi mikmod mmx mp3 mpeg msn mysql mysqli ncurses nls nptl nptlonly nsplugin odbc ogg opengl oss pam pcmcia pcntl pcre pdf perl php png posix ppds pppd python qt qt3 qt4 quicktime readline reflection samba scanner sdl session sharedmem soap sockets spell spl sse sse2 ssl svg tcpd theora threads tiff truetype truetype-fonts type1-fonts unicode usb utf8 vcd vhosts vorbis wifi win32codecs x86 xcomposite xine xinerama xml xmlrpc xorg xsl xv xvid xvmc zlib" ALSA_CARDS="intel8x0" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mulaw multi null plug rate route share shm softvol" ELIBC="glibc" INPUT_DEVICES="keyboard mouse synaptics" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LINGUAS="en_GB" USERLAND="GNU" VIDEO_CARDS="i810 fbdev vesa"
Unset:  CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LANG, LC_ALL, LDFLAGS, PORTAGE_RSYNC_EXTRA_OPTS
Comment 3 Doug Goldstein (RETIRED) gentoo-dev 2007-02-22 21:38:40 UTC
upstream has a new version available. wvstreams 4.3. It's possible it fixes the issues
Comment 4 Alin Năstac (RETIRED) gentoo-dev 2007-03-05 11:43:18 UTC
(In reply to comment #3)
> upstream has a new version available. wvstreams 4.3. 

Where do you find this version?
Comment 5 Serhij S. Stasyuk 2007-03-09 09:28:05 UTC
http://alumnit.ca/wiki/?WvStreams :
The latest version of WvStreams is maintained and released through AlumNit. Please go to AlumNit:WvStreams for more information.

http://alumnit.ca/wiki/?WvStreams
Comment 6 Serhij S. Stasyuk 2007-03-09 09:41:04 UTC
Compilation of 4.3 would be broken on machines with 64bit address:

// convert 'addr' to hex and write it to fd.
static void wra(int fd, const void *addr)
{
    char digits[] = "0123456789ABCDEF";

    write(fd, "0x", 2);
    for (int shift=28; shift>=0; shift-=4)
        write(fd, &digits[(((unsigned)addr)>>shift)&0xF], 1);
}

utils/wvcrash.cc: In function ‘void wra(int, const void*)’:
utils/wvcrash.cc:95: error: cast from ‘const void*’ to ‘unsigned int’ loses precision
Comment 7 Serhij S. Stasyuk 2007-03-09 09:51:27 UTC
ok, filled last comment under http://code.google.com/p/wvstreams/issues/detail?id=9&can=2&q=
Comment 8 Christoph Jacob 2007-03-09 10:31:53 UTC
I downloaded wvstreams-3.2 and changed the ebuild, and it fixes the initially reported problem. 

I have attached my updated ebuild. The patch files have to be renamed from 4.2.2 to 4.3, and also in the files 4.2.2 has to be replaced by 4.3 
(I dont know, I guess there is a better way to do this?)
The gcc-4.1 patch is not needed anymore, this change is included already. 
Comment 9 Christoph Jacob 2007-03-09 10:32:55 UTC
Created attachment 112684 [details]
ebuild for wvstreams-4.3
Comment 10 Serhij S. Stasyuk 2007-03-09 10:45:29 UTC
Pls, check proposed fix on 32-bit platform
(from http://code.google.com/p/wvstreams/issues/detail?id=9&can=2&q=) (pls, first try to compile and run test.c from wvstreams bug):

Add "#include <malloc.h>" if needed and change original wra to this code:

static void wra(int fd, const void *addr)
{
	const unsigned int ptrbitsshift = (sizeof(ptrdiff_t) << 3) - 4;
	char digits[] = "0123456789ABCDEF";

	write(fd, "0x", 2);
	for (int shift=ptrbitsshift; shift>=0; shift-=4)
		write(fd, &digits[(((ptrdiff_t)addr)>>shift)&0xF], 1);
}
Comment 11 Alin Năstac (RETIRED) gentoo-dev 2007-03-12 16:07:31 UTC
Thanks to all of you for your help! :)

I've added an unfinished version to the tree. It is hard masked so it shouldn't affect users. Please read the following and help me fixing it.

Problems that this version has:

  1) It cannot be linked with --as-needed. The output is:
x86_64-pc-linux-gnu-gcc -Lyes -Wl,-O1,--as-needed -Lyes -L/usr/qt/3/lib -L/usr/lib64/xplc-0.3.13 -lxplc -lxplc-cxx -ldl    -L.  -o crypto/tests/printcert crypto/tests/printcert.o libuniconf.so libwvstreams.so libwvutils.so libwvbase.so libwvtest.a     -lsupc++ -lgcc_eh   -lsupc++ -lgcc_eh
/usr/lib/gcc/x86_64-pc-linux-gnu/4.1.1/../../../../x86_64-pc-linux-gnu/bin/ld: warning: libwvutils.so.4.3, needed by libwvstreams.so, not found (try using -rpath or -rpath-link)
libwvstreams.so: undefined reference to `adler32'
libwvstreams.so: undefined reference to `crc32'
collect2: ld returned 1 exit status
make: *** [ipstreams/tests/unixtest] Error 1

  2) Has Q/A issues, although it seems to be more of a compiler problem (I only looked over urlget/wvhttppool.cc but seems to me compiler is wrong on this one; if class B is derived from A and I have a A* ptrToA variable, I should be allowed to cast this variable to B* without any warning). The Q/A warnings are:
 * QA Notice: Package has poor programming practices which may compile
 *            fine but exhibit random runtime failures.
 * utils/wvbdbhash.cc:109: warning: dereferencing type-punned pointer will break strict-aliasing rules
utils/wvbdbhash.cc:109: warning: dereferencing type-punned pointer will break strict-aliasing rules
utils/wvbdbhash.cc:112: warning: dereferencing type-punned pointer will break strict-aliasing rules
utils/wvbdbhash.cc:125: warning: dereferencing type-punned pointer will break strict-aliasing rules
utils/wvbdbhash.cc:145: warning: dereferencing type-punned pointer will break strict-aliasing rules
utils/wvbdbhash.cc:170: warning: dereferencing type-punned pointer will break strict-aliasing rules
utils/wvbdbhash.cc:170: warning: dereferencing type-punned pointer will break strict-aliasing rules
utils/wvbdbhash.cc:172: warning: dereferencing type-punned pointer will break strict-aliasing rules
utils/wvbdbhash.cc:230: warning: dereferencing type-punned pointer will break strict-aliasing rules
urlget/wvhttppool.cc:46: warning: dereferencing type-punned pointer will break strict-aliasing rules

Comment 12 Christoph Jacob 2007-03-12 17:26:49 UTC
Thanks a lot. 
The updated ebuild works fine for me on x86 (32 bit). I also
tried with --as-needed and it worked fine for me, I could not
reproduce the error message you got.
Comment 13 Serhij S. Stasyuk 2007-03-12 17:46:21 UTC
patch in portage (net-libs/wvstreams/files/wvstreams-4.3-64bit.patch) tree would compute first iterator value each time function enters, proposed - only during compilation.
Better is to use next patch:
diff -Nru wvstreams-4.3.orig/utils/wvcrash.cc wvstreams-4.3/utils/wvcrash.cc
--- wvstreams-4.3.orig/utils/wvcrash.cc 2007-02-07 21:06:12.000000000 +0200
+++ wvstreams-4.3/utils/wvcrash.cc      2007-03-09 13:09:44.000000000 +0200
@@ -88,11 +88,12 @@
 // convert 'addr' to hex and write it to fd.
 static void wra(int fd, const void *addr)
 {
+    const unsigned int ptrbitsshift = (sizeof(ptrdiff_t) << 3) - 4;
     char digits[] = "0123456789ABCDEF";
     
     write(fd, "0x", 2);
-    for (int shift=28; shift>=0; shift-=4)
-        write(fd, &digits[(((unsigned)addr)>>shift)&0xF], 1);
+    for (int shift=ptrbitsshift; shift>=0; shift-=4)
+        write(fd, &digits[(((ptrdiff_t)addr)>>shift)&0xF], 1);
 }
Comment 14 Martin Väth 2007-03-12 19:00:20 UTC
(In reply to comment #11)
>>   1) It cannot be linked with --as-needed.

That's not a bug or a QA issue. Just filter out --as-needed.

>   2) Has Q/A issues, although it seems to be more of a compiler problem

No, it is not a compiler problem, it is very serious:

> if class B is derived from A and I have a A* ptrToA variable, I should be
> allowed to cast this variable to B* without any warning.

(I guess you mean here: A is derived from B [by multiple inheritance!]).

Even this cast is problematic, because it might be necessary (for multiple inheritance) to change the pointer content: That's why you should actually use dynamic_cast<B*>(ptrToA) to do the casting.
However, in the code we have even a casting of A** to B**: That's semantically simply not possible, because for the "cast" all pointers in that "array of unknown size" would have to be converted.
So whether this works depends really on the compiler implementation and on accident (namely on whether it is necessary to modify the pointer for the conversion or not).

The other occurrences are even worse: There is a conversion of datum* to DBT* where datum and DBT seem to be rather unrelated classes (perhaps they have some members in common or both inherit eventually from the same class - I did not check - but whether this has the desired effect depends completely on accident and on the compiler implementation - and in this case also of the implementation of the database library).

Moreover, the "const" argument of function arguments given by reference is casted away in several of these occurrences - so I guess that the call to the database function where these casts are used will modify the passed "const" argument (at least it might do so - depending on the database implementation): I have some doubts that this side effect was really desired by the authors when they declared the argument "const".

So the QA warnings are more than appropriate. IMHO the code (or perhaps even the concept underlying it) is simply broken.
Comment 15 Alin Năstac (RETIRED) gentoo-dev 2007-03-13 07:47:46 UTC
(In reply to comment #13)
There is no performance loss in my solution - constant expressions are computed at compile time. On the other hand, the proposed version allocate a 32-bit integer on the stack, so I would say this version is the slow one ;)

(In reply to comment #14)
> That's not a bug or a QA issue. Just filter out --as-needed.

Hmm... then why the hell did I made that as-needed.patch? Seriously, this issue must be fixed. Currently I have no idea why is behaving like that (seems that the linker tries to load libraries instead linking with the ones found in -L paths).

> > if class B is derived from A and I have a A* ptrToA variable, I should be
> > allowed to cast this variable to B* without any warning.
> 
> (I guess you mean here: A is derived from B [by multiple inheritance!]).

Err... I wanted to say "if class B is derived from A and I have B* ptrToB variable, I should be allowed to cast this variable to A* without any warning". :\
I didn't referred to multiple inheritance at all, although I think this also should work. Care to explain to me what compiler would ever hold following expression as true? 
  (void*)dynamic_cast<A*>(ptrToB) != (void*)ptrToB

> However, in the code we have even a casting of A** to B**: That's semantically
> simply not possible, because for the "cast" all pointers in that "array of
> unknown size" would have to be converted.

A** (pointer to a pointer to an instance of A) is totally a different thing than A[][] (array of array of A instances). In the first case we know the exact size of that variable and it is independent of the size of the A ( the size is equal with sizeof(void*) ), while the second case we have an array of arrays of A, with a memory size == m * n * sizeof(A).
Comment 16 Martin Väth 2007-03-13 22:55:53 UTC
(In reply to comment #15)
> as-needed.patch? Seriously, this issue must be fixed.

Why? If the configure-script of the package isn't buggy (i.e. if no unneeded libraries are explicitly linked on the command line) --as-needed makes no difference (except only that it might drop actually needed libraries which occur only indirectly).

> Care to explain to me what compiler would ever hold following
> expression as true? 
>   (void*)dynamic_cast<A*>(ptrToB) != (void*)ptrToB

I haven't tried, but this should usually happen if B is derived (explicitly or implicitly) from more classes then A: There is no reason why just A should be the first object in B.

And even if you do not have multiple inheritance, an optimization step in the compiler might want to order the elements in B differently for better alignment. I have not checked whether gcc does this on some architectures. At least there is no guarantee that you get the correct thing if you don't use dynamic_cast: that's why this operator was introduced.

> > However, in the code we have even a casting of A** to B**: That's
> > semantically simply not possible, because for the "cast" all pointers
> > in that "array of unknown size" would have to be converted.
> 
> A** (pointer to a pointer to an instance of A) is totally a different thing
> than A[][] (array of array of A instances).

I didn't claim the contrary. What I mean is simply that you cannot convert
A **A_ptr_ptr to B **B_ptr_ptr, because in each occurrence of your code referring *B_ptr_ptr you would need a dynamic_cast (which of course code written to access B_ptr_ptr cannot know): The compiler is not able to convert in one command all pointers to which *B_ptr_ptr might ever refer (the collection of these hypothetical pointers I called "array of unknown size").

Anyway, this cast is not the worst one: The casts in wvbdbhash.cc worry me much more.
Comment 17 Christoph Jacob 2007-03-14 07:54:49 UTC
For all the discussion about the as-needed issue, 
I think this is what you are looking for:

http://www.gentoo.org/proj/en/qa/asneeded.xml
Comment 18 Alin Năstac (RETIRED) gentoo-dev 2007-03-14 09:12:13 UTC
I've fixed  the --as-needed problem by appending -Wl,-rpath-link,. to the LDFLAGS.
The only problem that still remains to be solved is the point number 2 of the comment #11.
Comment 19 Alin Năstac (RETIRED) gentoo-dev 2007-03-14 11:35:38 UTC
I've looked over the QA problems exposed at comment 11 and I see no real problem.

The detailed list:
  1) utils/wwbdbhash.cc
The conversions from (datum *) to (DBT *) is harmless. The definitions of those 2 structs are identical (datum is defined in include/wvondiskhash.h and DBT is defined in /usr/include/db_185.h). Furthermore, when a (const datum *) -> (DBT*) cast is used, it could be replaced with (const datum *) -> (const DBT*).
  2) urlget/wvhttppool.cc
As I said, the fact that compiler issue a type-punned warning about a conversion from A** to B**  (where B is ancestor of A) is simply broken. I've found that the only way to hide this warning is to use (void*).

Since I see no reason to add -fno-strict-aliasing to CFLAGS, I will add a patch that mask such warnings by casting to void*. 
However, I will wait a week for contra arguments (mostly I want to hear what cpp team has to say).
Comment 20 Martin Väth 2007-03-14 13:36:19 UTC
(In reply to comment #19)
> The conversions from (datum *) to (DBT *) is harmless.
> The definitions of those 2 structs are identical

...which by no language standard guarantees that these structs will be stored identically and with the same alignment: It is things like this which make code break in a hardly reproducible way even if only a slightly different library version or compiler/architecture/CFLAGS are used as the one it was originally tested. Even if the library was compiled just with a different setting might be a problem.

The real solution would be to "typedef DBT datum;" (I know that this is clumsy to patch into the current code, because the struct members are named differently).

> it could be replaced with (const datum *) -> (const DBT*).

It seems you are right. I don't know why I got compiler warnings about losing const-ness anyway when I tested this some days ago. I can't reproduce it now anymore, probably I made some mistake.

> As I said, the fact that compiler issue a type-punned warning about a
> conversion from A** to B**  (where B is ancestor of A) is simply broken.

I still don't agree, since it is compiler/optimization-dependent whether this works. For a proper code such a cast shouldn't be necessary unless it can be done with dynamic_cast.

> add a patch that mask such warnings by casting to void*.

Since the warnings *are* appropriate, I (as a user) would prefer to see them. I would suggest to leave them as they are (unless you can fix them properly, i.e. not just hiding them): If things go wrong for some people (e.g. on a less popular architecture or with certain library versions), one might get a hint where the cause might be - without warnings one is much more lost. But it is of course a question of policy...
Comment 21 Alin Năstac (RETIRED) gentoo-dev 2007-03-14 14:31:16 UTC
(In reply to comment #20)
> The real solution would be to "typedef DBT datum;" (I know that this is clumsy
> to patch into the current code, because the struct members are named
> differently).

I did it... then I realised I'm about to modify the interface of the WvBdbHash class, so I deleted the patch.

The structs we are talking about are:
   typedef struct {
     void *data;
     size_t size;
   } DBT;
and
   typedef struct {
     void *dptr;
     size_t dsize;
   } datum;

No matter what compiler you use or what architecture are you on, instances of these kinds of structs will be allocated like this:
   address of instance : data (or dptr)
   address of instance + sizeof(void*) : size (or dsize)

Except different alignment directives (not the case here), there is simply nothing that a compiler can do to screw the compatibility between these 2 structs.
Comment 22 Alin Năstac (RETIRED) gentoo-dev 2007-03-17 08:28:53 UTC
cpp team, do you have anything to say about it?
Comment 23 Alin Năstac (RETIRED) gentoo-dev 2007-03-17 08:33:47 UTC
...or maybe someone from toolchain team can prove me wrong?
Comment 24 Tanner Oakes 2007-03-20 18:40:19 UTC
Here is a patch that lets wvstreams compile with gcc 4.1.2.  It is from 
http://groups.google.com/group/wvstreams-devel/browse_thread/thread/883aaea2e38ae754/3abfdaaa1db72677?lnk=raot

I just added it into the other gcc41 patch stuff

--- wvstreams-4.2.2.orig/include/wvvector.h  (revision 11478)
+++ wvstreams-4.2.2/include/wvvector.h  (working copy)
@@ -347,7 +347,7 @@
     }

     /** A simple iterator that walks through all elements in the list. */
-    class Iter : public WvVector::IterBase
+    class Iter : public WvVectorBase::IterBase
     {
     public:
        /** Binds the iterator to the specified vector. */ 
Comment 25 Tiziano Müller (RETIRED) gentoo-dev 2007-04-01 19:42:34 UTC
mrness: The patch provided by Tanner Oakes seems reasonable. Do you think you could add it?
Comment 26 Alin Năstac (RETIRED) gentoo-dev 2007-04-01 21:56:35 UTC
Of course, but I'm still expecting an answer from toolchain or cpp herds. 
Comment 27 SpanKY gentoo-dev 2007-04-04 05:27:09 UTC
re:as-needed: the usage of -rpath-link is prob the best solution now ... this is why libtool is nice because it takes care of all that sort of crappy details ...

to the real meat ... throwing (void*) casts about will not always solve the problem ... ive seen a few different code bases that took pointers to floats and tried to directly cast them to integers so as to rip out specific bits ... the code started to fail oddly with gcc-4.1.x and -O2 and when we looked at the strict-aliasing issue, simply inserting a (void*) case inbetween the pointers did make the warning go away, but the resulting code was still broken at runtime ... so unless you can verify at runtime that the code behaves properly, i wouldnt really rely on that

the real solution is always to re-evaluate your code base in the first place to make the casts unnecessary ... since we're just package maintainers and dont really want to deal with that crap though, one method may be to utilize unions:
union {
   datum d;
   DBT D;
} u_newkey;
u_newkey.d = key;
...->seq(dbf, &u_newkey.D, ...

HTH
Comment 28 Alin Năstac (RETIRED) gentoo-dev 2007-04-04 09:10:33 UTC
fixed in net-dialup/wvstreams-4.3-r1

(In reply to comment #27)
I've applied the wvstreams-4.3-type-punned.patch, which use unions as you suggested.
Thanks, Mike!

(In reply to comment #24)
This patch is not necessary for wvstreams-4.3.
Comment 29 Serhij S. Stasyuk 2007-07-02 21:06:55 UTC
Just notice for maintainer. Just received email from William Lachance:
---
Hi,

Just thought you might like to know that I committed your patch to
make wvcrash compile on 64-bit machines. Your changes should be
available for everyone in WvStreams 4.4.
---

So, ebuild for 4.4 wouldn't need wvstreams-4.3-64bit.patch