sys-libs/libsmbios requires cflags unset else the compile will fail. Reproducible: Always Actual Results: Sorry. I don't have a saved clipping of the compiler error. Just know it will fail with the following cflags: CFLAGS="-march=pentium3 -O3 -pipe -fomit-frame-pointer" I think most low-level coding does require cflags unset, ie grub, in order to compile and execute safely. (Grub will compile, but will hang during execution.)
OK, attach build.log then.
Cannot reproduce
Created attachment 207949 [details] build.log -j2 is enabled along with: CFLAGS="-march=pentium3 -O3 -pipe -fomit-frame-pointer" CXXFLAGS="${CFLAGS}" LDFLAGS="-Wl,-O1"
Reopening bug. I've got a minute or so and will try building w/o a few optimizations to see if it's just a trivial thing.
So far, it seems to be the -O3 breaking the compile. Reducing to -O2, the compile completes.
Try again without distcc and attach the new build.log (if it still fails) and provide emerge --info.
Created attachment 208010 [details] Simplified build.log without distcc (and ccache) Comment #6 doesn't make sense. But for kicks, I compiled without cccache/distcc anyways as I forgot what the error was, and had another package complaining (with a diff error output -- but had to disable distcc anyways).
(In reply to comment #7) > Created an attachment (id=208010) [details] > Simplified build.log without distcc (and ccache) > > Comment #6 doesn't make sense. > > But for kicks, I compiled without cccache/distcc anyways as I forgot what the > error was, and had another package complaining (with a diff error output -- but > had to disable distcc anyways). > Before stating that a comment doesn't make sense, you should first properly read it. If you would have done so, you would have attached emerge --info and we would, among other things, know what compiler version you are using.
If you read the compiler output, you'll see this is a simple array issue and the compile is simply instructed to stop on all warnings. This is usually caused by a cflag designating all warnings to be treated like errors. I usually only enable such flags when I want to tackle all warnings within my code. There's also a pre-packaged binary within this ebuild source package: /var/tmp/portage/.../work/libsmbios-2.2.16/pkg/py-compile I'm marking this as works for me. Feel free to reopen if you want to fix it.
Using built-in specs. Target: i686-pc-linux-gnu Configured with: /var/tmp/portage/sys-devel/gcc-4.3.4/work/gcc-4.3.4/configure --prefix=/usr --bindir=/usr/i686-pc-linux-gnu/gcc-bin/4.3.4 --includedir=/usr/lib/gcc/i686-pc-linux-gnu/4.3.4/include --datadir=/usr/share/gcc-data/i686-pc-linux-gnu/4.3.4 --mandir=/usr/share/gcc-data/i686-pc-linux-gnu/4.3.4/man --infodir=/usr/share/gcc-data/i686-pc-linux-gnu/4.3.4/info --with-gxx-include-dir=/usr/lib/gcc/i686-pc-linux-gnu/4.3.4/include/g++-v4 --host=i686-pc-linux-gnu --build=i686-pc-linux-gnu --disable-altivec --disable-fixed-point --enable-nls --without-included-gettext --with-system-zlib --disable-checking --disable-werror --enable-secureplt --disable-multilib --enable-libmudflap --disable-libssp --enable-libgomp --disable-libgcj --with-arch=i686 --enable-languages=c,c++,treelang,fortran --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu --with-bugurl=http://bugs.gentoo.org/ --with-pkgversion='Gentoo 4.3.4 p1.0, pie-10.1.5' Thread model: posix gcc version 4.3.4 (Gentoo 4.3.4 p1.0, pie-10.1.5)
You said in comment 5 that it depends on the optimization level. This shouldn't be the case.
(In reply to comment #5) > So far, it seems to be the -O3 breaking the compile. Reducing to -O2, the > compile completes. > That's only part of the required information. You have to find the flag that's breaking it. It's simple, use "man gcc" as reference to see what's different between -O2 and -O3 optimization levels. Then use -O2 and add those flags, drop them until you find the offending one.
I reproduced it on amd64 with gcc-4.4.2. The fun thing is that the warning disappears when "-O2 + all options that are enabled with -O3"* is used. * -finline-functions -funswitch-loops -fpredictive-commoning -fgcse-after-reload -ftree-vectorize
Created attachment 208063 [details] reduced testcase gcc-4.4.2 -O2 -std=gnu99 -Wall -c testcase.c -> no warning gcc-4.4.2 -O3 -std=gnu99 -Wall -c testcase.c -> testcase.c:30: warning: array subscript is above array bounds gcc-4.4.2 -O2 -std=gnu99 -Wall -c testcase.c -finline-functions -funswitch-loops -fpredictive-commoning -fgcse-after-reload -ftree-vectorize -> no warning
Created attachment 208065 [details] more reduced testcase Compile with the same options as above. The warning can be triggered with -O2, if in line 6 the size of the array is lowered.
the bug here is that libsmbios is built with -Werror, which has nothing to do with toolchain. i still don't see emerge --info.
In ref to Comment #13. Ditto. I was also trying to view extended flags of -O? levels, but for some reason forgot how. Ditto concerning -Werror being set. I'm seeing it set within the Makefile.am & Makefile.in Of all likeliness, the reason Werror is set is likely because libsmbios binaries touches BIOS level code and is there to ensure the binaries created will be executing functions properly on the BIOS level code. Since I've had my Dell laptop, I don't think I've ever really used this package. The Service Tag ID is already provided in /proc by the in kernel I8K module. As such, libsmbios is kind of useless here. It's suppose to modify back light settings, etc. The only packaging seemingly requiring it is hal with use flag "dell". (ie. euses dell) Even then, it still doesn't appear to be needed on dell laptops(?) I'm in the midst of emerge system/world after a GCC upgrade -- thought I'd take the time to at least file. Simply unsetting the flags via a /etc/portage/env/sys-libs/libsmbios file resolves it here. Another hack that could be quickly performed if none of you use this package too, is use "strip-flags" to strip cflags within the ebuild and maybe post a warning pointing to this bug. (Mplayer's ebuild does this already.)
ignoring the -Werror, the code too is wrong (and the warning is correct) the reduced test case *is* exceeding the proper bounds. that struct is not packed which means you have 5 bytes of valid data followed by 1 padding byte followed by 2 bytes of valid data. however, still ignoring that buglet and the behavior of gcc is debatable. it will warn as soon as you exceed the array. you might be able to open a report upstream about that.
Ditto Spanky. I'm in the process of signing up and posting this issue on Dell's libsmbios mailing list. However, it appears there's been no newer releases of libsmbios since 2006. And the last reply on their mailing list from a Dell rep is July 2008. <shrugs> This bug is a duplicate of Bug #272128 and has a status of "RESOLVED NEEDINFO" Last comment was, "increase the array ptr or to substitute sizeof something more suitable" I'll forward this upstream / post on their mailing list.
Bug has been filed on Dell's libsmbios-devel mailing list and should show within October's archives (dated specifically, 2009.10.23). http://lists.us.dell.com/pipermail/libsmbios-devel/
(In reply to comment #18) > the reduced test case *is* exceeding the proper bounds. that struct is not > packed which means you have 5 bytes of valid data followed by 1 padding byte > followed by 2 bytes of valid data. > I should add that the original struct is defined as struct dmi_table_entry_point { u8 anchor[5]; u8 checksum; u16 table_length; u32 table_address; u16 table_num_structs; u8 smbios_bcd_revision; } __attribute__ ((packed));
Could you try with 2.2.19?
(In reply to comment #22) > Could you try with 2.2.19? Fails for me with -O3 on ~amd64 using gcc-4.4.2.
Created attachment 210828 [details] build-2.2.19.log Still fails to build with -O3. (Still compiles fine with -O2)
Absolutely still no activity from libsmbios mailing list or developers (after I reported this upstream).
Ah. We have activity on the Dell smbios mailing list. http://lists.us.dell.com/pipermail/libsmbios-devel/2009-December/000461.html The following is a quoted response: --- Begin of Snip --- Analyzing this code, I can only come to the conclusion that this is a completely bogus error. The code: u8 checksum = 0; const u8 *ptr = (const u8*)(dmiTEP); // don't overrun dmiTEP if BIOS is buggy... (note sizeof() test here) // added especially to deal with buggy Intel BIOS. for( unsigned int i = 0; i < sizeof(*dmiTEP); ++i ) // stupid stuff to avoid MVC++ .NET runtime exception check for cast to different size checksum = (checksum + ptr[i]) & 0xFF; The last line is what gives the warning. The 'ptr[i]' line is guaranteed to never overflow due to the sizeof() check in the for() loop. I've done some searches, but am not able to determine a way to change the code to supress this warning. My advice is "dont do that". I only recommend -O2 compilation, which I believe is the default. -- Michael --- End of Snip ---
Fix in CVS
And what happens when the offending flag from -O3 is moved to -O2 at some point? This isn't solved by replacing -O3 with -O2. The offending flag might as well be in -Os far as we know, since it hasn't been pinpointed to any particular flag here. When it has, the ebuild could have valid workaround as append-flags -fno-something.
Created attachment 216165 [details] Another testcase Here is my, very similar testcase. It have tested it with different gcc versions (including lateset ~x86) and with same results. Despite the original libsmbios compiles fine with -O2, this reduced testcase issues warning even with -O2!!! Moreover the "packed" attribute has no influence its behaviour. Summing up: -O0 and -O1 compile fine, -O2 and -O3 issue warning. See comments in the testcase for details. IMHO it is definitely a gcc bug. This bug should be reopened and/or new gcc bug should be opened.
FYI: libsmbios is now available by git. See recent libsmbios mailing list (dell.com) post? for further info, or dell.com's libsmbios project webpage.
