Re: Adding ~/.local/bin to default PATH
On Wed, Jul 27, 2011 at 04:24:06PM +0200, Miloslav Trmač wrote: IMHO the ~/.local/bin place is a mistake, and it's still not too late to stop making this mistake irreversible. Yeah. Every $PATH element has its runtime cost (execvp needs to search that path, at least for unsuccessful searches, or if a later element contains a dir which actually contains the right executable), and hiding a dir into which something stores executables that are to be found by default is certainly not desirable. Jakub -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: floppy support
On Tue, Aug 30, 2011 at 10:41:45PM -0500, Bruno Wolff III wrote:
%install
rm -rf $RPM_BUILD_ROOT
mkdir -p $RPM_BUILD_ROOT%{_libdir}/modules-load.d
echo floppy $RPM_BUILD_ROOT%{_libdir}/modules-load.d/floppy.conf
%{_sysconfdir} instead of %{_libdir} everywhere.
%files
%{_libdir}/modules-load.d/floppy.conf
Jakub
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Notice of intent: patching glibc
On Thu, Sep 01, 2011 at 09:34:10AM +0200, Andreas Schwab wrote: Adam Williamson awill...@redhat.com writes: But I did mention all the various bug reports - Arch and upstream - in my ML post on the topic: subject glibc causing crashes in most anything that does DNS lookups in F16. That is useless. Please always put such important information in the bug report, so that it can be found. It is also in bugzilla, just not in https://bugzilla.redhat.com/show_bug.cgi?id=730856 but in https://bugzilla.redhat.com/show_bug.cgi?id=732857 which has been marked as duplicate of that. You should always look at all the bugs dupped together to find more info about the bug if it isn't clear how to reproduce it. Jakub -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Notice of intent: patching glibc
On Fri, Sep 02, 2011 at 01:20:19PM -0700, Adam Williamson wrote: Is there a specific reason glibc does this? Yes. Can it not have a set of patches, one per change, as is usual practice? Fedora glibc sources are from git, and the bit diff is just generated diff between the upstream snapshot and corresponding Fedora snapshot, sans a few Fedora-only directories (which are packaged as extra tarball). Jakub -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Notice of intent: patching glibc
On Sat, Sep 03, 2011 at 09:38:46AM +0100, Richard W.M. Jones wrote: Fedora glibc sources are from git, and the bit diff is just generated diff between the upstream snapshot and corresponding Fedora snapshot, sans a few Fedora-only directories (which are packaged as extra tarball). That's not a reason. Why not keep the Fedora branch in git and make patches from it: https://rwmj.wordpress.com/2011/08/09/nice-rpm-git-patch-management-trick/ This method is quite probably simpler than the one you're using now. glibc is doing it that way for many years, even when it was diffing upstream CVS trunk vs. Fedora CVS branch, not sure if the Fedora changes from CVS era would result in something reasonable with your tricks, but moreover what glibc does now is fully scripted in the Makefiles and it would be extra work to change it to something different. I'd say it is up to the Fedora glibc maintainer to do it the way he prefers to (which is not me for a couple of years now). Jakub -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Compiling 32bit on 64bit Fedora
On Wed, Sep 07, 2011 at 11:52:58AM -0400, Nathaniel McCallum wrote: gcc -m32 -o foo foo.c gives me: /usr/include/gnu/stubs.h:7:27: fatal error: gnu/stubs-32.h: No such file or directory If I copy the gnu/stubs-32.h file from the 32bit glibc-devel package into the right place and run the command above again I get: /usr/bin/ld: cannot find crt1.o: No such file or directory /usr/bin/ld: cannot find crti.o: No such file or directory /usr/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-redhat-linux/4.6.1/libgcc_s.so when searching for -lgcc_s /usr/bin/ld: cannot find -lgcc_s /usr/bin/ld: skipping incompatible /usr/lib64/libc.so when searching for -lc /usr/bin/ld: cannot find -lc /usr/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-redhat-linux/4.6.1/libgcc_s.so when searching for -lgcc_s /usr/bin/ld: cannot find -lgcc_s /usr/bin/ld: cannot find crtn.o: No such file or directory collect2: ld returned 1 exit status Hrm... Am I doing something wrong? Or is this a packaging bug? I can't think of any reason why I shouldn't be able to compile at least a basic C program with no deps as 32bit on 64bit. No, it is a user error. The packaging goal is that nobody is forced to have 32-bit packages installed on x86_64 (and similarly for other architectures). So, if you want to compile/link 32-bit packages, you need to install a minimal set of 32-bit packages (at least yum install glibc-devel.i686 libgcc.i686 ). Jakub -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Development to release quality
On Mon, Sep 12, 2011 at 10:05:05AM -0400, Clyde E. Kunkel wrote: On 09/12/2011 06:01 AM, Matej Cepl wrote: Too much QA (or any external QA) imposed on the development make it slower. Compare Linux v. OpenSolaris kernel development. Fedora tries to be very fast developing distro, thus less QA in the development version. Ah yes, the ol' QA conundrum. There isn't enough when a bad product slips into production and there is too much the rest of the time. We need QA. We also need to remember QA's place in this world--support, not line management, not the the final arbiter. But then this is another long thread. Sure, we need QA, but for rawhide the development shouldn't be totally stalled as it is already in F16 right now, where updates for critpath packages, even when they have several hundred thousands of tests performed already during package building, just sit in bodhi for 2-3 weeks, often with first proventester karma after 12 or 14 days. Jakub -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [Guidelines Change] Changes to the Packaging Guidelines
On Thu, Sep 22, 2011 at 01:06:51PM -0400, Tom Callaway wrote: Here are the latest changes to the Fedora Packaging Guidelines: --- The section of the Packaging Guidelines regarding Compiler Flags has been updated and improved, most notably, to document handling of PIE enabled packages. https://fedoraproject.org/wiki/Packaging:Guidelines#Compiler_flags This adds -fPIC (if -fPIE is not already present) to the compiler flags, and adds -z now to the linker flags. That should be ... adds -fPIE (if -fPIC is not already present) ... I'd say. At least I hope that's what the spec change does, the initial version did that. Jakub -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [Guidelines Change] Changes to the Packaging Guidelines
On Thu, Sep 22, 2011 at 01:59:33PM -0400, Tom Callaway wrote:
On 09/22/2011 01:36 PM, Jakub Jelinek wrote:
That should be ... adds -fPIE (if -fPIC is not already present) ...
I'd say. At least I hope that's what the spec change does, the initial
version did that.
No, I'm fairly sure that it only adds -fPIC in scenarios where -fPIE is
not already passed. Adam can probably comment further on why.
Ah, I see:
%rename cc1_options rh_cc1_options_old
*cc1_options:
%{!fpie:%{!fPIE:%{!fpic:%{!fPIC:%{!fno-pic:-fPIC} %(rh_cc1_options_old)
That looks just wrong. -fpie/-fPIE is in general faster than -fpic/-fPIC,
because it can assume (non-weak) symbols defined in the object can't be
overridden. Without hardening, objects compiled without
-fpie/-fPIE/-fpic/-fPIC assume that too (and additionally are position
dependent), so I fail to see why you'd want to default to -fPIC. You
certainly want to default to -fPIE.
Jakub
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [Guidelines Change] Changes to the Packaging Guidelines
On Thu, Sep 22, 2011 at 02:18:10PM -0400, Adam Jackson wrote:
%rename cc1_options rh_cc1_options_old
*cc1_options:
%{!fpie:%{!fPIE:%{!fpic:%{!fPIC:%{!fno-pic:-fPIC} %(rh_cc1_options_old)
That looks just wrong. -fpie/-fPIE is in general faster than -fpic/-fPIC,
because it can assume (non-weak) symbols defined in the object can't be
overridden. Without hardening, objects compiled without
-fpie/-fPIE/-fpic/-fPIC assume that too (and additionally are position
dependent), so I fail to see why you'd want to default to -fPIC. You
certainly want to default to -fPIE.
You can't default to -fPIE because at cc1 time you don't know whether
the object is destined for a DSO or not, -fPIE will produce relocations
that aren't legal in DSOs, and ld isn't awesome enough to convert them
for you.
Such packages would be broken and would fail to link without hardening
or at least have text relocations too. Packagers shouldn't rely on
this spec hack to fix up their packaging bugs (or upstream bugs), the hack
should be just about changing position dependent binaries in the executable
into position independent binaries.
Jakub
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Another glibc change that nearly got pushed into F16
On Wed, Oct 26, 2011 at 10:06:31AM -0400, Tom Lane wrote: /usr/include/glib-2.0/glib/gmacros.h:32:2: error: #error Only glib.h can be included directly. or close variants of that. I assume this is another manifestation of the same bug being discussed here ... or have the glibc guys managed to break the world in two different ways in the same release? You are confusing glibc with glib here, the above very much looks like a glib bug, nothing to do with glibc. Jakub -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd acceptance, packaging guidelines (was Re: systemd and changes)
On Wed, Aug 25, 2010 at 04:08:49PM +0200, Lennart Poettering wrote: On Wed, 25.08.10 03:03, Miloslav Trmač (m...@volny.cz) wrote: The traditional solution is to reexec not on shutdown, but immediately after init upgrade (which also frees the inodes early); this can still race with shutdown in theory, but is probably good enough in practice. Well, while reexecing on package upgrades might kinda help fix the issue I think it doesn't really scale, because you'd have to reexec systemd when any of the libs it uses is upgraded, i.e. glibc, audit, selinux, tcpwrap, pam, libcap. glibc %post (and prelink cron scripts) already telinit u when libc/ld.so (resp. any library) changes. So I guess there's isn't really any other option then reexecing init in some way on shutdown. Jakub -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: -static packages
On Wed, Sep 15, 2010 at 05:06:20PM +0100, Robert Spanton wrote: I've recently had to link a fair amount of my work statically so that it'll run on a cluster of RHEL machines. Unfortunately, I am just a user of these machines, and so I don't have the power to get them to run Fedora or even to get the admins to install RHEL packages in a timely manner. Building statically also helps me to eliminate as many of the inevitable fractional differences between cluster nodes as possible, to achieve reproducible results from simulation runs. However, only a few packages in Fedora provide -static variants. This has meant that I've had to locally build these, which is obviously not desirable from a maintenance perspective. So, would be acceptable to register requests for -static package variants as tickets on bugzilla? Or is there a better way to try to encourage people to generate these packages? Better yet is not to link statically. http://www.akkadia.org/drepper/no_static_linking.html Jakub -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: -frecord-gcc-switches as default CFLAG?
On Mon, Nov 01, 2010 at 09:04:12AM -0400, Tom spot Callaway wrote: On 10/30/2010 06:01 AM, Richard W.M. Jones wrote: On Sat, Oct 30, 2010 at 02:24:02AM -0400, Jon Stanley wrote: I noticed on my Fedora 13 box that in the RPM macro %__global_cflags that -frecord-gcc-switches is missing, which is a nifty compiler feature that will record the flags passed to gcc in a section in the object file, thus aiding in the how in the world was this compiled? problem. An example: [jstan...@hawtness ~]$ gcc -O2 -frecord-gcc-switches -g -o hello hello.c [jstan...@hawtness ~]$ readelf -p .GCC.command.line hello String dump of section '.GCC.command.line': [ 0] hello.c [ 8] -mtune=generic [17] -g [1a] -O2 [1e] -frecord-gcc-switches What do folks think about adding this as a default? Any reason not to (other than possibly a few bytes extra in the object files)? +1 I think would also catch those cases where some gcc flag is found to break code generation. You reasonably see which binaries were affected. I agree. Unless there is a notable performance cost in this, I say we should go for it. -frecord-gcc-switches is unfortunately pretty much useless, see http://gcc.gnu.org/PR32998. Please don't add it, we want something actually usable, not this option. Jakub -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Compile with -fno-omit-frame-pointer on x86_64?
On Wed, Nov 03, 2010 at 02:48:12PM -0400, Owen Taylor wrote: Lack of decent profiling is a major problem for making our operating system fast. By far the most effective of profiling is sampling profile with callgraph information. Soeren's comment from March: http://lwn.net/Articles/380582/ Basically summarizes the situation, and as far as I know nothing has changed ... with default compilation options, getting callgraph profiling on x86_64 really requires a DWARF unwinder in the kernel. Which seems unlikely to happen. But that's the right thing to do. As a developer, your options for profiling are: - Recompile everything you care about profiling with -fno-omit-frame-pointer instead of using system packages. Instead of this, which really is a big performance penalty. Even i?86 is changing in GCC 4.6 to not do -fno-omit-frame-pointer by default. The unwind info recent GCCs provide is correct even in epilogues and can be relied upon. There are several lightweight unwinders that can be easily adapted for kernel purposes. Just talk to the systemtap folks. There is always callgrind if you don't want to recompile anything and need to profile something even when kernel doesn't support it. Jakub -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Compile with -fno-omit-frame-pointer on x86_64?
On Wed, Nov 03, 2010 at 03:20:59PM -0400, Owen Taylor wrote: On Wed, 2010-11-03 at 19:58 +0100, Jakub Jelinek wrote: On Wed, Nov 03, 2010 at 02:48:12PM -0400, Owen Taylor wrote: Instead of this, which really is a big performance penalty. Do you have a sense of the quantification of big here? I know in compiler terms, 1% is big, but we're no where close to wringing the last 1% out of overall Fedora performance. If you create a sufficiently complex system, there's lots of stupid stuff going on. And you can't find the stupid stuff without appropriate tools. The last numbers I was pointed at for x86_64 were 4% slowdown, which really is a lot and it takes several years to achieve that improvement on the compiler side. It seems like if it was that easy, it would have happened and we'd have a solution in the upstream kernel... I think we had one in the upstream kernel for some time, then Linus just didn't like to see it needing too many bugfixes needed for it and nuked it. (One thing that definitely makes things tricky is paging in debuginfo. I think I saw a discussion somewhere that systemtap preemptively was paging in all debuginfo for traced modules. That's tricky in systemwide Yeah, systemtap does that (and has that in kernel unwinder for userspace). Jakub -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Compile with -fno-omit-frame-pointer on x86_64?
On Wed, Nov 03, 2010 at 04:10:30PM -0400, Adam Jackson wrote: On Wed, 2010-11-03 at 19:58 +0100, Jakub Jelinek wrote: On Wed, Nov 03, 2010 at 02:48:12PM -0400, Owen Taylor wrote: Basically summarizes the situation, and as far as I know nothing has changed ... with default compilation options, getting callgraph profiling on x86_64 really requires a DWARF unwinder in the kernel. Which seems unlikely to happen. But that's the right thing to do. Sure, but so is a kernel debugger, and it's taken us over ten years to get one. I'm pretty okay with doing something wrong now if it gets me something usable for long enough to get something right later. I'll take 4% across the board if it helps me find the 20% that matters. Most of the time you don't find the 20% improvements with profilers though, so all we end up with is just slowing everything by 4%. Definitely a bad idea, now that per core performance doesn't increase very much and most programs aren't parallelized at all or just very badly. Jakub -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Backporting LLVM 3.1 for Fedora 17
On Fri, Nov 16, 2012 at 09:49:19AM -0500, Adam Jackson wrote: That said, llvm consumers are difficult to keep in sync with llvm anyway. Many llvm projects seem like they pick a point release to build against and then never get updated when the ABI changes. If we do this we might want to start by building compat-llvm30 for the libraries and migrating the consumers independently afterwards. It'd be fine if that compat package only lived for the one release that needs it (ie no compat-llvm30 in F18 or later, apps that aren't ported get deadpackaged), but at least that way we could avoid breaking llvm apps in F17 updates that worked in F17 gold. I guess for that it doesn't help that only one of the 4 llvm-libs shared libraries (libLLVM-3.*.so) has the version in its name, the other 3 clearly dependent on that one don't, eventhough I very much doubt they are anywhere close to be ABI compatible. Not to mention that somebody should tell the LLVM folks about the ld -soname option, none of those 4 have DT_SONAME. Jakub -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Results of a test mass rebuild of rawhide/x86_64 with gcc-4.8.0-0.1.fc19
Hi! As part of preparations for possible switch of system compiler in F19 to GCC 4.8.0, we (myself and Marek Polacek) have performed a test mass rebuild of rawhide (December 17th package list) using gcc-4.8.0-0.1.fc19 on x86_64, and for those packages that failed also rebuilt the same package with gcc-4.7.2-9.fc19 to quickly remove from the list packages that fail for non-gcc related reasons. 11687 packages built fine, 933 packages failed to build with both gcc-4.8.0-0.1.f19.x86_64.rpm and gcc-4.7.2-9.fc19.x86_64.rpm (ignored for this analysis, unlikely to be gcc 4.8 related). The remaining packages, that failed to build with 4.8.0-0.1 and succeeded with 4.7.2-9 are listed below. 67 of these look like issues on the package side, 22 gcc bugs that were supposedly fixed by now upstream and thus should be ok in 4.8.0-0.3 when it is built next week and 3 are not yet fixed gcc issues. CCing Benjamin if he is again interested in writing http://gcc.gnu.org/gcc-4.8/porting_to.html and could find this information useful. Besides build failures, the -Wsizeof-pointer-memaccess warning triggered in several packages that succeeded building, but it would be nice if package maintainers actually checked those and fixed up, most likely those are real package bugs. The list of such packages is included in first attachment. For the more aggresive loop optimizations if the loop contain undefined behavior, while it caused build failures just for 12 packages during the mass rebuild, supposedly more packages will be affected, just the problems weren't triggered during package build. Usually such loops are either turned into infinite loops that soon crash, or hang, or as can be seen on the perl-PDL case loops can be turned into just conditional non-looping code (e.g. when compiler assumes that it can validly loop just at most once). blktap-2.0.90-6.git20111216.62de90d.fc18.src.rpm cdrkit-1.1.11-14.fc19.src.rpm elfutils-0.155-1.fc19.src.rpm isomd5sum-1.0.9-2.fc18.src.rpm libopensync-plugin-opie-0.22-8.fc18.src.rpm linphone-3.5.2-4.fc18.src.rpm lldpad-0.9.45-3.fc19.src.rpm openvas-libraries-5.0.4-1.fc19.src.rpm pilot-link-0.12.5-13.fc18.src.rpm sh-elf-binutils-2.21-5.fc19.src.rpm packages built with -Werror, for which the new -Wsizeof-pointer-memaccess warning included in -Wall warns and -Werror makes a fatal error out of it bamf-0.2.104-4.fc18.src.rpm byzanz-0.3-0.5.fc17.src.rpm fvkbd-0.2.2-6.fc18.src.rpm gedit-collaboration-3.6.0-1.fc18.src.rpm gtkimageview-1.6.4-6.fc18.src.rpm gypsy-0.8-6.fc17.src.rpm libindicator-0.4.94-3.fc18.src.rpm ltrace-0.7.0-1.fc19.src.rpm mail-notification-5.4-64.git.eab5c13.fc19.src.rpm ModemManager-0.6.0.0-2.fc19.src.rpm physfs-2.0.2-3.fc18.src.rpm roboptim-core-0.5-6.fc18.src.rpm v8-3.10.8-2.fc18.src.rpm xen-4.2.0-6.fc19.src.rpm packages built with -Werror, for which the new -Wunused-local-typedefs warning included in -Wall warns and -Werror makes a fatal error out of it trafficserver-3.2.0-3.fc18.src.rpm package built with -Werror, and -Wmaybe-uninitialized warns about possibly uninitialized fields which are uninitialized if inc_gmtime_r returns -1 (and ink_time_current_mdy doesn't bother to check that return value) armacycles-ad-0.2.8.3.2-3.fc18.src.rpm irrlicht-1.8-1.fc19.src.rpm kdevelop-4.4.1-2.fc19.src.rpm kst-2.0.3-7.fc18.src.rpm maildrop-2.5.0-17.fc18.src.rpm megaglest-3.7.1-1.fc19.src.rpm opal-3.10.9-2.fc19.src.rpm oxygen-gtk2-1.3.1-1.fc19.src.rpm oxygen-gtk3-1.1.1-2.fc19.src.rpm supertuxkart-0.7.3-3.fc19.src.rpm syncevolution-1.3.2-1.fc19.src.rpm gcc bug - internal compiler error in inline_call, fixed upstream already, see http://gcc.gnu.org/PR55683 pari-2.5.3-1.fc19.src.rpm gcc bug - internal compiler error in LRA, fixed upstream already, see http://gcc.gnu.org/PR55775 avrdude-5.11.1-2.fc18.src.rpm gcc bug - internal compiler error in remove_redundant_iv_tests, fixed upstream already, see http://gcc.gnu.org/PR55684 openttd-1.2.2-1.fc19.src.rpm gcc bug - the package is built with LTO, and the problem is extremely hard to reduce, just rebuild without --with-lto for now b43-openfwwf-5.2-8.fc18.src.rpm ccache-3.1.8-1.fc18.src.rpm openchange-1.0-12.fc19.src.rpm openttd-opengfx-0.4.5-1.fc19.src.rpm samba-4.0.0-171.fc19.rc6.src.rpm /usr/include/stdc-predef.h issues gcc preprocessor now in C/C++ modes automatically includes stdc-predef.h header, packages which are using preprocessor for non-C/C++ code or doing weird things with the preprocessor might run into issues. For non-C/C++ code, it is always better to preprocess as assembly instead of C libxc-1.2.0-2.fc18.src.rpm /usr/include/stdc-predef.h issues - using cpp -C -ansi to preprocess Fortran sources is simply a very bad idea adobe-source-libraries-1.0.43-13.fc19.src.rpm asl-gcc.patch patch needs to be
Re: Results of a test mass rebuild of rawhide/x86_64 with gcc-4.8.0-0.1.fc19
On Fri, Jan 04, 2013 at 04:41:45PM -0500, Adam Jackson wrote: Thanks for this! One question... On Fri, 2013-01-04 at 21:40 +0100, Jakub Jelinek wrote: llvm-3.1-12.fc19.src.rpm gcc bug, not fixed yet, see http://gcc.gnu.org/PR55875 My reading of that bug is that -fno-ivopts could be a workaround? Worse code, but if my options are that and no llvm builds... Yes, but the other option is that the bug is just going to be fixed. It is a P1 bug, so a release blocker, after all. The real mass rebuild won't happen next week... Jakub -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Results of a test mass rebuild of rawhide/x86_64 with gcc-4.8.0-0.1.fc19
On Mon, Jan 07, 2013 at 03:50:01PM +, Petr Pisar wrote:
yap-6.2.2-4.fc18.src.rpm
similar to getdata bug:
LAST_FLAG = 23
...
#define NUMBER_OF_YAP_FLAGS LAST_FLAG
...
#define yap_flags Yap_heap_regs-yap_flags_field
...
Int yap_flags_field[NUMBER_OF_YAP_FLAGS];
...
/* This must be done before initialising predicates */
for (i = 0; i = LAST_FLAG; i++) {
yap_flags[i] = 0;
}
What's wrong with assigning 0 that fits into any intenger? C99 says:
6.3.1.3 Signed and unsigned integers
1 When a value with integer type is converted to another integer type
other than _Bool, if the value can be represented by the new type,
it is unchanged.
The pre-precessed code is:
for (i = 0; i = LAST_FLAG; i++) {
((all_heap_codes *)(0x1000))-yap_flags_field[i] = 0;
}
Type of yap_flags_field is int[].
That's not correct, type of yap_flags_field is int[NUMBER_OF_YAP_FLAGS]
aka int[LAST_FLAG]. The undefined behavior happens in the last iteration,
where you do
((all_heap_codes *)(0x1000))-yap_flags_field[LAST_FLAG] = 0;
ISO C99 6.5.2.1 says that this is equivalent to:
(*all_heap_codes *)(0x1000))-yap_flags_field)+(LAST_FLAG))) = 0;
and then 6.5.6/8 (last sentence) applies:
If the result points one past the last element of the array object, it
shall not be used as the operand of a unary * operator that is evaluated.
Note the array is in a middle of a structure, not at the end, where is the
only place where flexible array members could be present and as an extension
GCC allows even non-flexible arrays to be treated similarly to flexible
arrays (case where people use say struct S { ...; int a[1]; }; as some kind
of pre-C99 flexible array members).
Jakub
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Results of a test mass rebuild of rawhide/x86_64 with gcc-4.8.0-0.1.fc19
On Mon, Jan 14, 2013 at 06:08:21PM +0200, Ville Skyttä wrote: On 2013-01-04 22:40, Jakub Jelinek wrote: gcc-4.8.0-0.1.fc19 on x86_64 I see this in git, but not even a scratch build in koji. Is a build of the 4.8.0 gcc and friends available somewhere? What about the build logs of the failed packages? -0.1 isn't in git nor scratch (wasn't ever in git, the scratch build has been deleted automatically long time ago already). In git there is -0.3, with http://koji.fedoraproject.org/scratch/jakub/task_4843433/ scratch build until it is deleted. Jakub -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Results of a test mass rebuild of rawhide/x86_64 with gcc-4.8.0-0.1.fc19
On Mon, Jan 14, 2013 at 11:32:09AM -0500, Dave Jones wrote: On Fri, Jan 04, 2013 at 09:40:27PM +0100, Jakub Jelinek wrote: The remaining packages, that failed to build with 4.8.0-0.1 and succeeded with 4.7.2-9 are listed below. 67 of these look like issues on the package side, 22 gcc bugs that were supposedly fixed by now upstream and thus should be ok in 4.8.0-0.3 when it is built next week and 3 are not yet fixed gcc issues. I'm pleasantly surprised that the kernel isn't in the failure list. No issues at all ? Or was it skipped for some reason ? Kernel built. I haven't tried to boot it though, for all packages it was just a test whether packages build (which includes fatal testsuite failures for tests they perform during the build). Jakub -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Shall we modify '-g' to '-g3' to have gcc save the macro info?
On Wed, Jan 16, 2013 at 02:26:00PM +0100, Jan Kratochvil wrote: On Wed, 16 Jan 2013 04:12:29 +0100, xning wrote: Shall we should modify '-g' to '-g3' to have gcc save the macro info? So when we install *-debuginfo packages, we can look up a macro definition, just like we can look up a function definition. That would be great, I have not found any official request for it, there was only short -g3 discussion in: Summary/Minutes from today's FESCo Meeting (2012-06-18) http://lists.fedoraproject.org/pipermail/devel/2012-June/168884.html The new -g3 format by Jakub Jelinek has only very small debug info size increase requirement (FIXME: missing numbers here). The tests performed on average meant that all or most of the space savings thanks to dwz were consumed again by the .debug_macro addition (+ .debug_str growth), which is why I've given up on the request to use -g3 in RPM_OPT_FLAGS by default. Jakub -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: GCC48 - switch GCC in Fedora 19 to 4.8.x, rebuild all packages with it
On Wed, Jan 16, 2013 at 08:21:24PM +0100, Tomas Mraz wrote: On Wed, 2013-01-16 at 14:15 -0500, Matthew Miller wrote: GCC 4.8.0 is going to be released in mid March to mid April and is currently in regression bugfix only mode. I've performed a test mass rebuild on x86_64 Looking at the schedule Wouldn't it be better to do the mass rebuild in Rawhide before the branch? If we're really looking at a second-half-of-May final release, that means beta testing ends the beginning of May, which possibly puts the window for the rebuild _after_ the beta release (let alone before the branch). If we're going to have a short F19 cycle, maybe this should be accepted now for F20 and happen in Rawhide after the branch. Or, if the F19 cycle is to be longer, maybe that's not an issue. Unless we're really confident that this won't cause problems. I'd say that if FESCo accepts this feature for F19, it implicates making the F19 schedule long enough to accommodate the rebuild before branching. If this is decided upon soon, the gcc packages could be ready for a mass rebuild around end of January or even slightly earlier. The package is in git right now, but so far built just as scratch builds. Jakub -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: GCC48 - switch GCC in Fedora 19 to 4.8.x, rebuild all packages with it
On Wed, Jan 16, 2013 at 11:52:04AM -0800, Brendan Conoboy wrote: On 01/16/2013 11:19 AM, Kevin Fenzi wrote: We need to decide the schedule soon IMHO. Perhaps the schedule should be decided in part on time to do mass rebuild after gcc 4.8.0 is released. The ARM team would really like to see 4.8 in F19 because 4.8 is the first gcc with native Aarch64 support. The mass rebuild doesn't have to be with a released compiler (and in fact, usually has been performed with a prerelease compiler), it is just important that the release is released with a released compiler. Jakub -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: GCC48 - switch GCC in Fedora 19 to 4.8.x, rebuild all packages with it
On Wed, Jan 16, 2013 at 12:38:29PM -0800, Brendan Conoboy wrote: Even better! Will the 3 failed builds mentioned at the beginning of the thread be resolved by the end-of-January estimated ready to go time? Are there any outstanding bugs in the 4.8-pre compiler that might have major impact on Fedora? If gcc 4.8 has progressed to the point that it's safe to use I'd love to see it done in F19. Two of the issues are resolved already, one (--with-lto issue in some game) probably not, but so difficult to reduce that it is probably better to suggest not using LTO there for now. Jakub -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: GCC48 - switch GCC in Fedora 19 to 4.8.x, rebuild all packages with it
On Thu, Jan 17, 2013 at 12:45:04PM +0100, Nikola Pajkovsky wrote:
is gcc bug[1] fixed in 4.8.0? it could bring a lot of nasty problems
with app which using atomit_t (unsigned long)
[1] http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55981
I think it isn't yet committed, has been approved though.
Not sure why do you mention it though, 4.7.x has the same bug
(and older gcc's didn't have __atomic_store{,_n} builtins),
so if some code in Fedora hits that issue, it already has that problem in
F17/F18.
Jakub
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Odd Problems to build inn on rawhide
On Thu, Jan 17, 2013 at 02:30:09PM +0100, Jochen Schmitt wrote: Hallo, during my last build of inn on rawhide I have got the following odd error messages: RPM build errors: bogus date in %changelog: Wed Jan 13 2009 Ondrej Vasik ova...@redhat.com - 2.4.5-7 bogus date in %changelog: Fri Jul 7 2008 Ondrej Vasik ova...@redhat.com - 2.4.5-2 bogus date in %changelog: Sun Jul 10 2000 Bill Nottingham nott...@redhat.com Can't mix special %doc with other forms: samples It may be nice, if anyone may have some hints to solve this issue. date -d 'Jan 13 2009'; date -d 'Jul 7 2008'; date -d 'Jul 10 2000' Tue Jan 13 00:00:00 CET 2009 Mon Jul 7 00:00:00 CEST 2008 Mon Jul 10 00:00:00 CEST 2000 so, either the days of the week or dates are wrong in the ChangeLog. No idea about the last message. Jakub -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: GCC48 - switch GCC in Fedora 19 to 4.8.x, rebuild all packages with it
On Tue, Jan 22, 2013 at 09:22:00PM +0100, Erik van Pienbroek wrote: Jaroslav Reznik schreef op wo 16-01-2013 om 12:35 [-0500]: See https://lists.fedoraproject.org/pipermail/devel/2013-January/175876.html for details. Once gcc-4.8.0-* is built into Fedora, after a few days or weeks a mass rebuild should be performed. I see that gcc 4.8 was just imported in rawhide some hours ago. What's the plan next? Will the rebuilds happen in a side-tag or in the master It hasn't been imported into rawhide yet, it was just built (first two non-scratch builds) and (almost) immediately untagged, just so that before tomorrow's FeSCo meeting there are packages already available and ready to be tagged into f19 instantly. Jakub -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: MEMSTOMP
On Thu, Jan 24, 2013 at 01:29:36PM -0500, Bill Nottingham wrote: Jaroslav Reznik (jrez...@redhat.com) said: = Features/MEMSTOMP = https://fedoraproject.org/wiki/Features/MEMSTOMP Feature owner(s): Jeff Law l...@redhat.com Include the MEMSTOMP DSOs in Fedora 19 to enable developers to more quickly detect certain library calls which result in undefined behaviour due to overlapping memory arguments. == Detailed description == MEMSTOMP is a DSO which can be preloaded by an application to detect calls to library routines with overlapping memory arguments. Specifically MEMSTOMP will detect calls to the following routines with overalapping memory arguments: [w]memcpy, str[n]cat, wcs[n]cat, str[n]cpy, wcs[n]cpy, [w]mempcpy, memccpy, stp[n]cpy While valgrind can detect these cases, using a DSO such as MEMSTOMP can be significantly faster. The MEMSTOMP code utilizes GPLV2+ and LGPL3 code. The GPLV2+ code is limited to the backtrace code which is not thread safe and may need to be disabled/rewritten. I assume this could be done as a system-wide LD_PRELOAD if desired? If all multiarch versions are installed, yeah, you could put /usr/$LIB/memstomp.so into /etc/ld.so.preload Jakub -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: GLIBC 2.17
On Tue, Jan 29, 2013 at 10:39:21AM +0100, Florian Weimer wrote: On 01/28/2013 06:31 PM, Bill Nottingham wrote: Florian Weimer (fwei...@redhat.com) said: See http://sourceware.org/glibc/wiki/Tips_and_Tricks/secure_getenv for code snippets to implement in the change in a backwards-compatible fashion. Unfortunately, glibc upstream insistent on renaming before making the symbol official. I'm a little confused by the 'unfortunately' here - if apps are using a private symbol, they should expect that they may need to change later. Precisely because it's in the private namespace, glibc could just have documented the existing __secure_getenv symbol. It's not that there aren't any public functions starting with __. But this was rejected by upstream, and now we have the __secure_getenv compatibility symbol (not usable for fresh linking), secure_getenv, and __libc_secure_getenv for internal glibc use (but which is still public for technical reasons). A @@GLIBC_PRIVATE symbol is not public. Jakub -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: systemd features
On Wed, Jan 30, 2013 at 07:18:40PM +0100, Tomas Mraz wrote: The point is, we've done this in the past where we shipped the data with the tools, and we very quickly moved to shipping the data separate - it's cleaner, allows for just updating the data when necessary, and it forces people to keep their API ABI for accessing it stable. :) +1 million - another data point - ca-certificates package - it was much cleaner to split it out of openssl. Ditto splitting of timezone data from glibc-common to tzdata. Jakub -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: LD Changes To Implicit DSO Linking Update
On Tue, Feb 09, 2010 at 11:09:50PM +0530, Parag N(पराग़) wrote: Anyway I find adding missing DSO to CFLAGS in SPEC is easy solution for now. They don't belong to CFLAGS, those are flags for compilation. You want LDFLAGS or even better add it in configure to LIBS. Jakub -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: LD Changes To Implicit DSO Linking Update
On Tue, Feb 09, 2010 at 07:42:44PM +0100, Kevin Kofler wrote: Adam Williamson wrote: I disagree with that. Previous changes to the build environment - even upstream GCC changes - have broken way more packages (every GCC .x release tends to break a lot of things temporarily). And that's something which really irks me about GCC upstream, they don't seem to understand what backwards compatibility means. That doesn't mean it's a good idea to break code like this. You are probably looking for bug compatibility, and that isn't something GCC guarantees, definitely not between major versions. The C/C++ standards (and standards governing the extensions to the languages) is what matters, if you write standard conforming code, GCC won't (intentionally) start rejecting it. But if you have code that happens to compile because of some GCC bug, eventhough it was invalid, or some C/C++ defect report clarifies some corner case, you need to be prepared to fix up your code. Jakub -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: LD Changes To Implicit DSO Linking Update
On Tue, Feb 16, 2010 at 03:57:52PM +0100, Gerd Hoffmann wrote: Well. Even pretty fundamental GNOME stuff like gtk2-devel is still broken. Look here: [r...@localhost ~]# pkg-config --libs gtk+-2.0 -pthread -lgtk-x11-2.0 -lgdk-x11-2.0 -latk-1.0 -lgio-2.0 -lpangoft2-1.0 -lgdk_pixbuf-2.0 -lpangocairo-1.0 -lcairo -lpango-1.0 -lfreetype -lfontconfig -lgobject-2.0 -lgmodule-2.0 -lgthread-2.0 -lrt -lglib-2.0 -lX11 is missing (at least, maybe more). Any gtk app using pkg-config to figure which libraries are required fails to build now. Only if the library you are compiling actually uses any libX11 APIs. If it only uses APIs from the named libraries, it will link fine. Jakub -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: gcc internal error on F13
On Sat, Mar 06, 2010 at 08:44:13AM -0500, Sam Varshavchik wrote: Paulo Cavalcanti writes: « HTML content follows » I am trying to build a package on F13, and got a gcc internal error: URL:http://koji.fedoraproject.org/koji/taskinfo?taskID=2034791http://koji .fedoraproject.org/koji/taskinfo?taskID=2034791 I have no idea how to proceed Create a bug against gcc. Given that the bug is preventing a package build, it should be a high priority bug to fix. Well, in this case it is not clear whether it is a gcc bug. gcc was OOM killed by the kernel, whether it is a gcc bug or not depends on whether gcc uses way too much memory compared to how complicated/large the source is. The OOM could be very well caused by some other memory demanding build going on at the same time on the same build box. So, first try to build it again, and only if it fails on the same file again, preprare a preprocessed source and file a bug against gcc. Jakub -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Announcing `gold-rebuild' - link your packages with gold now
On Mon, Mar 08, 2010 at 09:24:29AM -0500, Frank Ch. Eigler wrote: Michal Nowak mno...@redhat.com writes: Past months I spent investigating `gold' - the new GNU linker and how it now works with stock Fedora packages. [...] Do your scripts provide some evidence of exciting speedups with gold? Or slowdowns? Jakub -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: does mc really require perl*?
On Fri, Sep 20, 2013 at 08:37:50PM +0200, Reindl Harald wrote: well, some people would now say i do the same i can say for sure to some other pakcages on a cloud server where they would disagree and because everybody has different needs keep the dependency chain as small as possible is always a good idea for a lot of reasons and save ressources is generally a good idea even if most of the young devlelopers never learned how to develop tiny, bugfree and stable software - the results are well known But for the mc dependency on perl, I'd say it is very reasonable one to have, because otherwise none of the extfs will really work, that is something used pretty frequently in mc. Of course unless you are prepared to rewrite all the scripts into awk, plain sh or something that will require smaller footprint. Jakub -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F20 System Wide Change: ARM as primary Architecture
On Tue, Oct 15, 2013 at 02:16:28PM -0400, Carlos O'Donell wrote: There is no effective security difference between accessing the randomized stack guard value from a global variable or a value stored in the dynamic thread vector. It is only a performance optimization. The choice of a global variable vs. DTV offset has only to do with the speed of access of the stack guard. DTV access is of course going to be expensive, after all, that is a function call, the question was about reserving a word at fixed constant offset from the TLS base and how expensive that is vs. global variable access. For soft FP I guess global variable access must win, for -mtp=cp15 ]it depends on how fast the mrc instruction is. Jakub -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: libtool broken in Koji F19 buildroot?
On Thu, Oct 17, 2013 at 07:38:59PM +0100, Richard W.M. Jones wrote:
While preparing the buildroot, Koji is saying:
DEBUG util.py:266: Error: Package: libtool-2.4.2-16.fc19.x86_64 (build)
DEBUG util.py:266: Requires: gcc = 4.8.1
DEBUG util.py:266: Installed: gcc-4.8.2-1.fc19.x86_64
(@build/$releasever)
DEBUG util.py:266: gcc = 4.8.2-1.fc19
(Full log:
http://kojipkgs.fedoraproject.org//work/tasks/2021/6072021/root.log )
That is a temporary measure, for the F19 gcc errata I need to rebuild
various packages which unfortunately hardcode hard dependency on gcc
%{version} (gcc-python-plugin, libtool, llvm, dragonegg). I have the first
two built now, third is building, 4th I need ACLs for or wait for the owner
to build. Once that is done, gcc 4.8.2 buildroot override will be expired
again.
Jakub
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: FTBFS if -Werror=format-security flag is used
On Wed, Dec 04, 2013 at 05:11:16PM -0600, Ian Pilcher wrote: On 12/04/2013 04:56 PM, Brendan Jones wrote: Patching is not a problem. Unnecessary is the question. Explain to me (not you in particular Rahul) how these printf's can possibly be exploited? char *output; output = get_user_input(...); printf(output); What happens when the user enters %n? With -D_FORTIFY_SOURCE=2 the program is aborted, unless the string resides in read-only memory ;) Jakub -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: FTBFS if -Werror=format-security flag is used
On Fri, Dec 06, 2013 at 08:02:06PM +0100, Kevin Kofler wrote:
* translatable format strings, e.g.
printf(translate(processed %d items), foo);
Translatable strings are handled just fine.
Try e.g.:
extern int my_printf (void *my_object, const char *my_format, ...)
__attribute__ ((format (printf, 2, 3)));
extern char *my_dgettext (char *my_domain, const char *my_format)
__attribute__ ((format_arg (2)));
void *p; char *q;
void
foo ()
{
my_printf (p, my_dgettext (q, abcd));
}
e.g. libintl.h already uses the right attributes, so you don't
get errors for this.
Jakub
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: FTBFS if -Werror=format-security flag is used
On Mon, Dec 09, 2013 at 03:01:55PM -0800, Les Howell wrote: unless something has changed recently fputs and puts just like gets and fgets have been deprecated and are discouraged due to potential security issues. That is wrong. Only gets is deprecated (removed in C11, obsolescent in POSIX 2008, etc.), because it fills in a buffer without telling the library the size of the buffer, so it is pretty much always a security issue to use gets. All other functions you've listed aren't deprecated at all. Jakub -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: missing on bodhi: gcc-c++-4.8.2-5.fc19.x86_64
On Wed, Dec 11, 2013 at 05:42:16PM +0100, Reindl Harald wrote: http://koji.fedoraproject.org/koji/buildinfo?buildID=483733 [root@testserver:~]$ rpm -qa | grep gcc gcc-c++-4.8.2-5.fc19.x86_64 libgcc-4.8.2-5.fc19.x86_64 gcc-4.8.2-5.fc19.x86_64 are these packages are missing on bodhi? http://bodhi.fedoraproject.org/ i would like to give positive karma after build MariaDB, Apache, PHP and VMware-Workstation kernel-modules succesful with it Please see http://gcc.gnu.org/PR59470, gcc-4.8.2-5 shouldn't be added. I'm debugging it right now, worst case I'll revert the offending commit if there is no fix available soon. Jakub -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fixing the glibc adobe flash incompatibility
On Thu, Nov 18, 2010 at 10:14:58AM +, Andrew Haley wrote: On 11/17/2010 11:42 PM, Kevin Kofler wrote: How is any of that a reason not to patch glibc? Upside of patching: happy users. Downside: nothing. Downside: slower memcpy on sse4.2 machines Downside: if we workaround the Adobe flash bug by reverting that change for say half a year to let Adobe fix it in the months timeframe, another possible misuses of memcpy in other proprietary closed software won't be detected over that period of time, so then we'll revert it for another buggy program and so on forever Downside: this isn't ever going to be acceptable to upstream If you want to workaround the bug somewhere, do it temporarily in nspluginwrapper, or the browser upon detecting loading of libflashplugin.so. Jakub -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fixing the glibc adobe flash incompatibility
On Thu, Nov 18, 2010 at 10:09:56AM -0500, Genes MailLists wrote: On 11/18/2010 09:28 AM, Jakub Jelinek wrote: Downside: nothing. Downside: slower memcpy on sse4.2 machines Do you know how much slower in absolute time is it? And is it (or would it be) visible (1/10's of seconds) or invisible (ms) in some typical (or atypical) apps that call memcpy() ... ? Depends on the application, but certainly memcpy is one of the most performance critical functions, it is used basically everywhere and heavily so, I've very often see it very high in oprofile dumps etc. For memcpy both performance with very small length is criticial (most programs call memcpy with small lengths) but many apps also copy large memory blocks around (which is where SSE*, nontemporal stores etc. play role). E.g. the latter measurably shows up on SPEC2k/SPEC2k6. It is very sad that Intel/AMD just didn't make sure rep movsb isn't the fastest copying sequence on all of their CPUs, which underneath could do whatever magic based on size and src/dst alignment (e.g. for small length handle it in hw so it is as quick as possible, for larger sizes perhaps handle it in microcode) - rep movsb can be easily inlined and is quite short as well. But on many, especially recent, CPUs it performs very badly compared to these much larger SSE* optimized routines. If you want exact numbers, best ask Intel folks who wrote and tuned the SSE4.2 memcpy routine. Jakub -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fixing the glibc adobe flash incompatibility
On Thu, Nov 18, 2010 at 04:39:40PM +0100, Magnus Glantz wrote: So.. Upside of patching: happy users :-) Downside of patching: unhappy developers :-( and unhappy users because their software runs slower, apparently you've (intentionally?) missed that. There is absolutely no reason to punish all sanely written apps for one badly written proprietary one. As I said earlier, if you can't live without the proprietary blob and for whatever reason can't just use the 32-bit one using nspluginwrapper (as 64-bit one is not in a yum repository using the 64-bit one is a security risk, because very few people will keep tracking new versions of it, downloading them as tarball and installing them), let's do the workarounds in nspluginwrapper or browser for libflashplayer.so only, not in glibc where it will affect all apps. Jakub -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Package rebuilds for gcc bug https://bugzilla.redhat.com/show_bug.cgi?id=634757
On Tue, Nov 23, 2010 at 03:45:26PM -0800, Jesse Keating wrote: gcc - update in -candidate, ping jakub Just remove gcc from your list. gcc is bootstrapped, so the installed gcc only builds first stage, everything else is built by (one of the) newly built compiler(s). So, gcc in f14 surely doesn't have that problem in it. I'll eventually do a f14 gcc errata, but only when I accumulate more fixes... Jakub -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: GCC bug 634757 F14 rebuild status
On Thu, Dec 02, 2010 at 12:03:42AM -0500, Matt McCutchen wrote:
On Wed, 2010-12-01 at 20:29 -0600, Dennis Gilmore wrote:
/usr/bin/install -c -m 644 'doc/examples/runExample.sh'
'/builddir/build/BUILDROOT/libgnome-java-2.12.7-2.fc14.1.i386/usr/share/doc/libgnome-java-2.12.7/examples/runExample.sh'
/usr/bin/install -c 'doc/examples/runExample.sh'
'/builddir/build/BUILDROOT/libgnome-java-2.12.7-2.fc14.1.i386/usr/share/doc/libgnome-java-2.12.7/examples/runExample.sh'
...
/usr/bin/install: cannot create regular file
`/builddir/build/BUILDROOT/libgnome-java-2.12.7-2.fc14.1.i386/usr/share/doc/libgnome-java-2.12.7/examples/runExample.sh':
File exists
When this succeeds, the permissions are unpredictably 644 or 755.
The solution: patch the package to not do that, or just try again and
hope you get lucky.
Or don't use %{_smp_mflags} for make install, just for make.
Parallelized make install doesn't work for many packages, and doesn't buy
much anyway.
Jakub
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Go frontend, GCC 4.6, F15
On Fri, Dec 03, 2010 at 08:28:20PM +0200, Albert Strasheim wrote: The Go frontend has been committed to GCC trunk: http://gcc.gnu.org/ml/gcc/2010-12/msg00117.html I checked the wiki, but there doesn't seem to be any mention of GCC 4.6 on the F15 feature list: http://fedoraproject.org/wiki/Releases/15/FeatureList Does anybody have any idea on the plans for GCC 4.6 and F15, and what kind of work would have to be done to get the Go frontend included? Our goal is to have GCC 4.6 as the system compiler in F15, we're currently working hard upstream bugfixing and stabilizing it. I'll write a F15 feature page soon. Jakub -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Removing -fexceptions from $RPM_OPT_FLAGS
On Tue, Jan 18, 2011 at 06:08:37PM -0500, Frank Ch. Eigler wrote: -fexception allows a C library to participate in C++ exception handling. It does not cost anything except extra data tables in the ELF file. Its presence matters in cases where a C library is used by a C++ program, for example where the library may make a callback into the C++ program, and that callback might throw an exception. With -fexception, that exception will be propagated properly through the C library, to the outermost application. Without it, exceptions thrown from a callback may abort the program, even if the overall application wanted to catch it. -fexceptions is also desirable for POSIX thread cancellation. Jakub -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: heads-up: systemtap-sdt-devel rebase in rawhide
On Wed, Jan 19, 2011 at 03:52:24PM +, Mark Wielaard wrote: Dan Horák dan at danny.cz writes: there is some clash in min/max macros/functions, but I've not done any detailed investigation yet, Tom has been notified. I asked Stan Cox, who said he was using the following workaround: I guess you could just make sure limits is included #ifdef __cplusplus before including whatever header defines these max/min macros (or in it before the definition). Jakub -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: heads-up: systemtap-sdt-devel rebase in rawhide
On Wed, Jan 19, 2011 at 04:49:04PM -0500, Frank Ch. Eigler wrote:
tgl wrote:
[...] I think the only near-term fix is to turn off dtrace support
in mysql. [...]
We'll do one better; we'll add a hack to sys/sdt.h to make mysql build
and respin systemtap today or tomorrow.
But the real issue here is that systemtap has got to be more chary of
what they expose into application namespace, or this same scenario is
going to be played out again and again.
I agree. It's not a great situation, but local GCC/C++ experts have
found no better way to type-analyze the parameters, to ensure their
safe passage to the tool. (Our testing shows limits is not
offensive to other C++ apps we've seen.)
If you really want to avoid #include limits in sys/sdt.h, you can, e.g. by
using
templatetypename __sdt_T
struct __sdt_type
{
static const bool __sdt_signed = false;
};
#define __SDT_ALWAYS_SIGNED(T) \
template struct __sdt_typeT { static const bool __sdt_signed = true; };
#define __SDT_COND_SIGNED(T) \
template struct __sdt_typeT { static const bool __sdt_signed = ((T)(-1)
0); };
__SDT_ALWAYS_SIGNED(signed char)
__SDT_ALWAYS_SIGNED(short)
__SDT_ALWAYS_SIGNED(int)
__SDT_ALWAYS_SIGNED(long)
__SDT_ALWAYS_SIGNED(long long)
__SDT_COND_SIGNED(char)
__SDT_COND_SIGNED(wchar_t)
#if defined (__GNUC__) (__GNUC__ 4 || (__GNUC__ == 4 __GNUC_MINOR__ =
4))
__SDT_COND_SIGNED(char16_t)
__SDT_COND_SIGNED(char32_t)
#endif
Jakub
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: About mtune=atom
On Mon, Jan 24, 2011 at 12:55:59PM -0500, Bill Nottingham wrote: Jakub Jelinek (ja...@redhat.com) said: On Mon, Jan 24, 2011 at 09:25:45AM -0800, John Reiser wrote: Actually many of them should be using the new x86_32 software architecture, which is the 64-bit instruction set (thus 16 general registers, SSE, ...) but with integers, longs, and pointers all 32 bits. The upper 32 bits of any user address are 0, and not stored in RAM (except the return address of CALL.) This gives a measurable benefit on boxes with low RAM. Except that such a model is only barely supported in binutils, the support for it in gcc is pre-alpha state on a branch and there is no kernel nor glibc support. Am I missing something, or would this also be binary-incompatible? If so, that's very very very much not worth the effort. Yes, it is ABI incompatible, not sure what made hjl start with that now and trying to push x86_64 into Irixy shape with 3 multilibs instead of 2. I vaguely remember we've talked about it a decade ago and decided it was not worth the effort. Jakub -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: gcc 4.6 for package monkeys
On Fri, Jan 28, 2011 at 08:26:36AM +0100, Julian Sikorski wrote: I have just run into an issue with gcc-4.6, namely RPM Fusion's mame failed to compile [1]. I was told that #include stddef.h was missing. So I have two questions: why did including this header directly became necessary (code builds fine with 4.5) and are there any other issues we package monkeys might run into with a new compiler? Some C++ headers were including cstdef header internally just so that they could use std::size_t and std::ptrdiff_t. Those types are in 4.6+ defined in an internal libstdc++ header using compiler builtin preprocessor macros (that existed for a while), so if you need anything else from cstddef/stddef.h, you need to include it yourself, as basically none of the standard C++ headers include cstddef any more. For more details see: http://gcc.gnu.org/ml/gcc-patches/2010-06/msg00257.html http://gcc.gnu.org/viewcvs?root=gccview=revrev=160231 Jakub -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: gcc 4.6 for package monkeys
On Thu, Jan 27, 2011 at 11:29:45PM -0800, Garrett Holmstrom wrote: On 1/27/2011 23:26, Julian Sikorski wrote: I have just run into an issue with gcc-4.6, namely RPM Fusion's mame failed to compile [1]. I was told that #includestddef.h was missing. So I have two questions: why did including this header directly became necessary (code builds fine with 4.5) and are there any other issues we package monkeys might run into with a new compiler? GCC 4.6 changed a lot of compiler warnings to errors, so a lot of code (especially C++ code) that used to get away with violations like omitting headers or assigning to un-assignable things will now fail to build. Care to share details? Of course there were many changes in the C++ FE, especially for C++0x, and maybe some warnings changed into errors, but nothing I'd describe as a lot. We haven't still written http://gcc.gnu.org/gcc-4.6/porting_to.html so if you have interesting info about changes that affect a lot of packages, details would be certainly welcome. The STL changes not to include cstddef internally is certainly one thing that will be added there. Jakub -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
GCC 4.6 related common package rebuild failures (was Re: mass rebuild status)
Hi!
On Tue, Feb 08, 2011 at 06:23:57PM -0600, Dennis Gilmore wrote:
so the mass rebuild is 24 hours in we have completed ~45% of the builds and
are at 365 packages failed to build the total number of builds in the mass
rebuild is 10404 we are churning along nicely. i expect to complete the first
pass sometime in the next 24 hours. so far i think its going pretty well
some web pages to look at http://ausil.fedorapeople.org/rebuild.html and
http://ausil.fedorapeople.org/failed.html these 2 pages are updated ~ every
10
minutes. Please drop into #fedora-devel on freenode if you have any questions.
I went through the failed.html list from shortly after you mailed this,
looking for errors related to GCC 4.6 (and sometimes even 4.5).
Here are some common errors. Please try to fix the issues rather than
adding workaround flags like -fpermissive, -Wno-unused-but-set-variable etc.
Benjamin, do you plan to write http://gcc.gnu.org/gcc-4.6/porting_to.html?
This could serve as partial source for that page.
-Werror=unused-but-set-variable
void fn (void)
{
int foo;
foo = bar ();
/* foo is never used. */
}
This is a new warning, which warns about variables that are only
ever set, but never otherwise used. Usually such variables useless
and often even the value assigned to them is computed needlessly,
sometimes expensively. In such cases you should just drop the
vars and initializers. Sometimes functions called during the
initialization have important side-effects for the program,
so you really need to read the source. So sometimes you want
to drop the unuse variables, but keep some function calls from
their initialization in the code. In some cases (often from
macro expansion) you just want to keep such unused variables
around. You can in that case just cast them to void,
or add __attribute__((__unused__)) to them. As this is just
a warning, it is usually just a nice to fix thing, but for packages
that are compiled with -Werror it is a must fix.
STL headers not including cstddef any longer
If you see errors like
'ptrdiff_t' does not name a type
'size_t' does not name a type
'NULL' was not declared in this scope
'size_t' has not been declared
'offsetof' was not declared in this scope
there are no arguments to 'offsetof' that depend on a template
parameter, so a declaration of 'offsetof' must be available
or warnings like
perhaps the 'offsetof' macro was used incorrectly
then most likely you have C++ code that includes some
STL headers and relied on them bringing in stddef.h
and is using ::ptrdiff_t, ::size_t, offsetof or NULL
macros. The STL headers now just declare std::ptrdiff_t
and std::size_t itself when needed, and no longer bring
in stddef.h, so if you use the global namespace types
from stddef.h or offsetof/NULL, just include cstddef
explicitly.
uninitialized const
struct A { int a; A (); };
struct B : public A { };
const B b;
now gets an error:
error: uninitialized const ‘b’ [-fpermissive]
note: ‘const struct B’ has no user-provided default constructor
This is related to http://gcc.gnu.org/PR43890, B above doesn't
have a user provided default ctor, so either an initializer
needs to be provided, or the default ctor needs to be added.
reference ‘...’ cannot be declared ‘mutable’
struct A { mutable int p; int q; A () : p(q) {} };
http://gcc.gnu.org/PR33558
Just remove mutable keyword from references.
taking address of temporary
struct S { S (); int i; };
void bar (S *);
void foo () { bar (S ()); }
http://gcc.gnu.org/viewcvs?root=gccview=revrev=164704
http://gcc.gnu.org/ml/gcc-patches/2010-09/msg02144.html
This used to be just a warning, now it is an error (unless
-fpermissive). Please don't add -fpermissive, instead just
add a variable and pass address of the variable if at all
possible.
duplicate member
struct A { int *a; union { struct { int *a; }; }; };
used to be diagnosed just by C++ FE, now since
http://gcc.gnu.org/PR4784 it is diagnosed also by C.
Because of the anonymous unions/structs there is ambiguity
about what .a actually refers to, one of the fields needs
to be renamed.
unrecognized option '-combine'
The -combine option has been removed, it has been very buggy and has
been superceeded by -flto. Either drop it, or build with -flto.
-export-dynamic
Some packages are passing -export-dynamic to gcc/g++ drivers,
when they should be using -Wl,-export-dynamic or -rdynamic or
-Wl,-E. See
Re: gcc-4.6.0-0.11.fc15.x86_64 breaks strcmp?
On Mon, Mar 07, 2011 at 05:09:17PM +0100, Jim Meyering wrote:
I suspect that there was a problem with .11, perhaps one of these:
* Fri Mar 04 2011 Jakub Jelinek ja...@redhat.com 4.6.0-0.12
- update from trunk
- PRs c++/46159, c++/46282, c++/47200, c++/47774, c++/47851, c++/47950,
c++/47974, c/47963, libstdc++/47913, middle-end/47283,
rtl-optimization/47925, target/47935, tree-optimization/47890
- rebuilt against ppl 0.11.2, reenable cloog-ppl Requires
because I can't reproduce that with the latest in rawhide,
gcc-4.6.0-0.12.fc15.x86_64:
You forgot to #include string.h
$ cat k.c
:
#define STREQ(a,b) (strcmp((a),(b)) == 0)
int
do_rm_rf (const char *path)
{
int r;
char *buf, *err;
if (STREQ (path, /))
{
reply_with_error (cannot remove root directory);
return -1;
}
}
$ gcc -O3 -c k.c -Werror=strict-overflow
:
I can reproduce it and have filed http://gcc.gnu.org/PR48022 for it.
Jakub
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: gcc-4.6.0-0.12.fc15.x86_64 breaks strcmp?
On Mon, Mar 07, 2011 at 05:15:18PM +0100, Jim Meyering wrote:
With the former and -O3, I do see your warning.
Here's a pared-down test case:
$ cat k.c
#include string.h
void do_rm_rf (const char *p) { if (strcmp (p, /) == 0) return; }
$ gcc -Wall -O3 -c k.c -Werror=strict-overflow
k.c: In function ‘do_rm_rf’:
k.c:2:1678: error: assuming signed overflow does not occur when changing
X +- C1 cmp C2 to X cmp C1 +- C2 [-Werror=strict-overflow]
cc1: some warnings being treated as errors
FYI, as a workaround -D__NO_STRING_INLINES should work, then strcmp
isn't expanded to the fancy glibc expansion...
Jakub
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Using LD_PRELOAD wrappers to identify problem use of shared library functions
On Thu, Mar 10, 2011 at 11:25:38AM -0500, William Cohen wrote: Shared library are heavily used through Linux distributions. Unfortunately, there are cases of functions in the libraries having undefined behavior. Rather than immediately reporting the dependence on that undefined behavior, the applications may later fail in odd and seemingly random ways. On particular example of this problem is the memcpy function which has undefined behavior when the source and destination regions overlap. This resulted in the following bug being filled about Strange sound on mp3 flash website: http://koji.fedoraproject.org/koji/taskinfo?taskID=2898613 The diagnosis of this problem was not straightford because the memcpy silently corrupted the data in the copy. There are many other examples of this type of memcpy problems in bugzilla. What would be desirable is catching the dependency on undefined behavior when it occurs. The LD_PRELOAD environment variable allows wrappers for shared library functions to be inserted. These wrappers can do additional checks and flag those issues when they occur. The mutrace package in Fedora is one example of this approach. It makes use of this mechanism to instrument the mutex operations and can trigger a gdb breakpoint when a problem mutex operation occurs. I have taken the code in the mutrace package and made memstomp which looks for the memcpy of overlapping regions. git repo at: http://fedorapeople.org/gitweb?p=wcohen/public_git/memstomp;a=summary A fedora scratch package RPM at: http://koji.fedoraproject.org/koji/taskinfo?taskID=2898613 Valgrind does check the arguments for memcpy (and many other memory related checks). The main advantage to using the specialized wrappers like memstomp is lower overhead. Most people are not willing to pay for the overhead that valgrind introduces (4x-100x slow downs). The overhead for the memstomp wrappers should be low enough that it would be feasible to set the LD_PRELOAD for Fedora alpha releases. This would make the problems depending on undefined behavior obvious rather than spending a large amount of time trying to replicate the problem and then diagnosing it. Nice, but I think the dlsym (NULL, main) lookup should not be done, at least not by default, we really don't want to encourage people linking programs with -rdynamic, that adds a runtime penalty. And, it would be nice when you have such a library not to check just memcpy, there are plenty of other commonly used calls which could be warned about. memcpy, strcpy, strncpy, strcat, strncat, strtok, strtok_r, mempcpy, strsep, stpcpy, stpncpy, memccpy just to name a few from string.h, then for -D_FORTIFY_SOURCE also __memcpy_chk, __mempcpy_chk, __strcpy_chk, __stpcpy_chk, __strncpy_chk, __stpncpy_chk, __strcat_chk, __strncat_chk. In wchar.h e.g. wcscpy, wcsncpy, wcscat, wcsncat, wcstok, wmemcpy, wmempcpy and maybe mbrtowc, wcrtomb, mbrlen, mbsrtowcs, wcsrtombs, mbsnrtowcs, wcsnrtombs, wcstol, wcstoul, wcstoll, wcstoull, ... Maybe also sprintf/snprintf if format string contains some %s/%ls/%S specifiers and those arguments overlap the target. Basically, most of the __restrict/restrict qualified prototypes in glibc headers would be good candidates for overlap tests (if possible to determine length). In the implementation of the checking library you probably want to #include sys/cdefs.h, then #undef __restrict #define __restrict and similarly for restrict and __restrict_arr and compile the file with -fno-builtin, to make sure gcc doesn't optimize your checks away based on the arguments being restricted pointers. Jakub -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Shared library permissions in Debian-land and Red Hat-land
On Wed, Mar 23, 2011 at 09:52:24PM -0700, John Reiser wrote: they say on Debian and Ubuntu, all shared libs have 0644 permissions. What they say is incorrect. Well, given that libc.so and ld.so are shared libraries with with meaningful e_entry, so you can actually run /lib/ld-2.*.so or /lib/libc-2.*.so, those definitely should be 755. The question is about libraries which just segfault when you try to exec them (most of the shared libraries). I have Ubuntu 10.10 i686: -rwxr-xr-x 1 root root 1421892 2011-01-21 15:08 /lib/libc-2.12.1.so Jakub -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: 9base in Fedora?
On Thu, May 26, 2011 at 02:18:07PM +0200, Petr Sabata wrote:
I'd like to thank all for their input.
As I understand it, the best way to do this in Fedora, with respect to
same ideas in this thread, would be having %{_libexecdir}/plan9 or similar,
with bin, lib and share (or whatever upstream supplies) subdirectories.
You understood it wrong, %{_libexecdir}/plan9 should contain only binaries
and nothing else, the rest would go into %{_libdir}/plan9.
Jakub
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: selinux alert from gccgo
On Thu, Jun 09, 2011 at 11:26:26AM -0400, Daniel J Walsh wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 06/09/2011 09:19 AM, Neal Becker wrote: I just compiled 'hello world.go' with gccgo on F15 and got selinux alert about mmap_zero when executable was run. THen I would open a big bug with gccgo and tell them to fix their code. mmap_zero is a known attack vector for exploiting kernel flaws, and almost no applications should need this access. Here is a discussion on it, and the problems that it caused SELinux. http://eparis.livejournal.com/ See https://bugzilla.redhat.com/show_bug.cgi?id=693143 mmap_zero audit message sounds like a kernel bug rather than gccgo, all it needs is executable stack (well, I think it really wants executable heap but is marked as needing executable stack). It has been reported to Ian, but nothing has been rewritten upstream yet. Jakub -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd: please stop trying to take over the world :)
On Wed, Jun 15, 2011 at 11:12:35AM -0400, Daniel J Walsh wrote: On 06/15/2011 11:03 AM, Miloslav Trma? wrote: On Wed, Jun 15, 2011 at 4:44 PM, Stephen Smalley s...@tycho.nsa.gov wrote: Ways to improve the situation for systemd would include: - Only load a subset of file_contexts entries, similar to udev. - Only load the file contexts entries temporarily, using selabel_open + selabel_close to bracket entire blocks where files are created or relabeled. - At policy build time, precompute a DFA for all of the regexps, and store it in a file. This file could be mmap()ed into any user of the policy, requiring no malloc(), and allowing the kernel to free the memory when it is no longer used; this should also make loading of the file_contexts configuration faster. Mirek I was wondering if this was possible. Any example of how to do it? At least with glibc regex, that would be terribly unportable and wouldn't buy much, as regcomp isn't very expensive, the DFA nodes are created on the fly during regexec as needed. Jakub -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Plan for tomorrow's FESCo meeting (2011-06-21)
On Fri, Jun 24, 2011 at 05:16:12PM -0400, Adam Jackson wrote:
and compiling it. In this case, -z relro on its own will not help: the
address of the 'exit' function isn't known until it's first called,
because function resolution is normally done lazily, and because the
'exit' symbol is not provided in the executable itself. So the
exit_type_array will end up in the final executable in a writeable
section. However, -z relro _will_ constify relocations that end up as
part of the same linked object, eg, a function defined in one
translation unit whose address is taken in another.
If instead you say both -z relro and -z now, then you are explicitly
asking the runtime linker to resolve all symbols up front. In this case
the address of 'exit' _will_ be known before ctors are run, which means
the array can be emitted in a .data.rel.ro section, which is initially
writeable but made read-only after relocations.
For binaries the address of 'exit' will be actually the exit@plt address
in the .plt section of the binary, and for symbols that don't have plt
entries in the binary, it is still a normal relocation against the symbol.
Only .rel{,a}.plt relocations are resolved lazily, all other relocations
are always resolved immediately. So if you have relocation against exit
in .data.rel.ro section in a shared library, it will be resolved right away
and then .data.rel.ro can be write protected if PT_GNU_RELRO covers it.
Either it will resolve to exit@plt in the binary if any, or to the
definition. With -z now in addition to -z relro, the only differences
are that .dynamic flags will tell ld.so to disable lazy relocation
and that PT_GNU_RELRO will also cover the .got.plt section, which is
normally after the PT_GNU_RELRO section, so it can be written into.
Jakub
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: question about -fstack-protector and fedora
On Thu, Jun 30, 2011 at 03:19:10PM +0200, Reindl Harald wrote: as far as i can see fedora is built with -fstack-protector and not -fstack-protector-all - is there a specific reason for not using the all variant Sure, it is expensive to set up the canary even when it is obvious it isn't needed. We by default use 4 byte+ arrays as the trigger to add stack canaries (gcc default is 8 byte+), with -fstack-protector-all you add it even for functions that don't have any stack variables at all, or that have only scalar vars etc. Jakub -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: question about -fstack-protector and fedora
On Thu, Jun 30, 2011 at 03:31:24PM +0200, Jakub Jelinek wrote:
On Thu, Jun 30, 2011 at 03:19:10PM +0200, Reindl Harald wrote:
as far as i can see fedora is built with -fstack-protector and not
-fstack-protector-all - is there a specific reason for not using
the all variant
Sure, it is expensive to set up the canary even when it is obvious
it isn't needed. We by default use 4 byte+ arrays as the trigger to
add stack canaries (gcc default is 8 byte+), with -fstack-protector-all
you add it even for functions that don't have any stack variables at
all, or that have only scalar vars etc.
I'd add that even functions as simple as
int foo (void) { return 1; }
are protected with -fstack-protector-all, with -fstack-protector
this function has 2 instructions, with -fstack-protector-all 11, which
includes creating a stack frame etc.
Really, -fstack-protector --param=ssp-buffer-size=4 is carefully chosen
reasonable default, just don't listen to clueless LFS/Gentoo folks
that suggest something else.
Jakub
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: glibc 2.14-4 eats my data (Re: F15 ext3, eCryptfs + samba = data corruption (Re: F15 Error mounting eCryptfs: [-5] Input/output error on different disks))
On Fri, Jul 08, 2011 at 01:12:04PM -0400, Steve Clark wrote: So it does appear to be related to the memcpy change in libc. So eCryptfs is buggy, just fix it. The compatibility stuff that has been added to glibc to workaround buggy old programs was just for programs linked against old glibc. If you compile it again and you want it still working, fix it. It isn't that hard. Jakub -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: glibc 2.14-4 eats my data (Re: F15 ext3, eCryptfs + samba = data corruption (Re: F15 Error mounting eCryptfs: [-5] Input/output error on different disks))
On Fri, Jul 08, 2011 at 01:27:45PM -0400, Steve Clark wrote: memove should be used if areas overlap that are being copied. If they overlap or may overlap. Jakub -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F18 feature: MiniDebugInfo
On Mon, May 07, 2012 at 04:25:46PM +0200, Jan Kratochvil wrote: On Mon, 07 May 2012 15:07:20 +0200, Alexander Larsson wrote: I just wrote a new Feature proposal for shipping minimal debug info by default: https://fedoraproject.org/wiki/Features/MiniDebugInfo The several choices is missing the primary possibility of no debug info needed at the client side at all thanks to already implemented https://fedoraproject.org/wiki/Features/RetraceServer Why not to use ABRT Retrace Server for the bugreports instead? I am only aware the upload of core file may be slow but that can be solved (by gdbserver for core files, which was already implemeted once). I do not know if it is a real problem or not, core file do not have to be large. For bug reporting, you don't need to upload core files, if all you want is to augment backtraces with symbol info and perhaps line info, then all you can do is just upload backtraces without symbol info/line info, supply the relevant build-ids for addresses seen in the backtrace and let some server with access to debuginfo packages finish that up. Jakub -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F18 feature: MiniDebugInfo
On Mon, May 07, 2012 at 05:25:29PM +0200, Jan Kratochvil wrote: On Mon, 07 May 2012 16:34:27 +0200, Jakub Jelinek wrote: For bug reporting, you don't need to upload core files, if all you want is to augment backtraces with symbol info and perhaps line info, then all you can do is just upload backtraces without symbol info/line info, supply the relevant build-ids for addresses seen in the backtrace and let some server with access to debuginfo packages finish that up. This will lose a lot of info, any local variables, function parameters, even inlined functions etc. Lose info compared to what? If debuginfo isn't installed on the client side, only this minidebug info is there, then that info wouldn't be provided either, so just adding the symbol (and/or line info) stuff on the server shouldn't make (much difference), unless the backtrace uses symbol or line info internally for heuristics etc. (but we really should be emitting async unwind info anyway already). Jakub -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F18 feature: MiniDebugInfo
On Tue, May 08, 2012 at 08:09:04AM +0200, Alexander Larsson wrote: This is your opinion. I rarely need the full backtrace in a bug report, because it you can get one its generally something thats easily reproduced and I can just run it in gdb myself. When you need it is when something weird is happening and you have to rely on the bugreport only. This is sometimes doable even without debug info, I even wrote a blog post about this: http://blogs.gnome.org/alexl/2005/08/26/the-art-of-decoding-backtraces-without-debug-info/ But, having the full symbol names for all libraries and apps in all backtraces I'll ever see in the future would help me immensely. Even if its just an unwinder. But for that you really don't need the symtabs stored in the binaries/shared libraries, you can just have the backtrace without symbols printed + print relevant build-ids at the beginning, a script at any time can reconstruct that into not just the symbol names, but also lineinfo. And the build-ids will help even if you want to look at further details (.debug_info, source files). Jakub -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F18 feature: MiniDebugInfo
On Tue, May 08, 2012 at 08:34:57AM +0200, Alexander Larsson wrote: Its true that that is all the information you need from the process/core. But you need to have the rest of the information availible *somewhere*, such as on a global retrace server or just having it Yes. locally in the minidebuginfo. The later is far more robust and simple. It lets you directly get a reasonable backtrace given *only* the actual binaries in the running process. What is far more robust and simple is something we simply have to agree to disagree on. Jakub -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F18 feature: MiniDebugInfo
On Wed, May 09, 2012 at 01:44:03PM +0200, Alexander Larsson wrote: I'm not proposing that we drop the existing backtraces with full debug info, but (appart from the other places where backtraces are also useful) I'd like it if ABRT could somehow catch all the cases where people abort a bugreport because things are scary/slow/bad network/whatever and at least report the low quality backtrace, which should be very quick and require little work from the user. But you don't need any kind of minidebuginfo for that first step, you can make it even faster by just uploading the backtrace + build-ids and on the server side the rest of transforming that to a low-quality backtrace can be handled automatically, without further user intervention, in case the user didn't go through to uploading the high quality thing from retrace server. Jakub -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: x32 abi support?
On Wed, May 16, 2012 at 04:28:31PM +0200, Lennart Poettering wrote: Mhmm, so I was under the impression that x32 was mostly about increasing the scalability of virtualized systems. i.e. run a higher number of x32 containers/VM on an x86_64 host. Most server software that is run in containers/VMs does not require 64bit address space, and hence using x32 for them should be quite benificial so that you can run more containers/VMs per host. After all this would reduce memory and CPU consumption of each, and due to smaller memory usage also result in less IO? Note that x32 is less secure than x86-64, the possible address space randomization is much more limited there, while there is ASCII armor, it can protect just a couple of libraries, unlikely all of them. With LP64 certain kinds of exploits are harder. And, for various programs you usually don't need 64-bit address space, but in the case where you have say bigger input you are simply out of luck if you are limited to 32-bit address space. Say with compilers/linkers, you can usually compile smaller stuff just fine with 32-bit compiler, but if you have some larger source code, x32 won't do it. Similarly various other programs that don't have constant memory requirements, but linear (or worse) with the size of the input. Jakub -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: How to proceed with MiniDebugInfo
On Thu, May 24, 2012 at 04:19:15PM +0200, Jan Kratochvil wrote: do better is too ambiguous and probably not right. Duplication matching can be always done server-side. Minidebuginfo may give less load for ABRT servers for example, this does not match the do better phrase. And the symbols for the duplication matching aren't as important, it is enough if the reporting client transforms addresses in the unwind address list into build-id + offset form, then it can be matched on the server side too. Only if you want to fuzzy match bugreports from different NVRs, then offsets are not useful and symbol names only sometimes useful. But the build-id + offset form can be transformed into more detailed forms on the server easily. Jakub -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: prelink should not mess with running executables
On Thu, Jul 19, 2012 at 07:10:18AM -0400, Sam Varshavchik wrote: What's a special-case band-aid about it? It looks perfectly reasonable to me. Why wouldn't you restart init? Why would you?If there's nothing wrong with with overwriting an executable, and, after all, that's how UNIX worked forever, then why bother restarting init? prelink/rpm/install etc. don't overwrite binaries, they write a temporary file in the same directory and rename over an executable, that is the standard UNIX way of upgrading stuff atomically. The reason for restarting init is that init is special, if you don't restart it, you have trouble on system shutdown, because the still used deleted files (init + shared libraries it uses) prevent from unmounting / cleanly. These days I think init reexecs itself during shutdown sequence anyway, so we might as well get away without restarting it. Jakub -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: prelink should not mess with running executables
On Fri, Jul 20, 2012 at 07:08:39AM -0400, Sam Varshavchik wrote: ??? prelink most certainly does NOT restart every daemon. prelink restarts init because historically init didn't always re-exec itself at shutdown, which in turn caused the root filesystem to not be cleanly unmounted. There was no need to reexec init until prelink came along. False. glibc %post had to (and still does AFAIK) rexec init too. Jakub -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: DWARF 4
On Fri, Dec 09, 2011 at 01:16:42PM -0700, Jerry James wrote:
Are there known obstacles in the way of replacing -g with -gdwarf-4
-fvar-tracking-assignments in our %{optflags}? I'm eager to be rid
of gdb telling me that the one value I really have to know to diagnose
a crash has been optimized away. Are there bits of the toolchain that
can't handle DWARF 4? Will debuginfo grow significantly in size?
For -OX -g (for X != 0) -fvar-tracking-assignments is the default
and in F16+ GCC also -gdwarf-4 is the default (with -fno-debug-types-section
, as .debug_types is still not supported by many tools and has lots of
unsolved problems even on its own, but otherwise you get all the DWARF4
goodies and in F16 also a bunch of new extensions).
F16 gdb doesn't support DW_OP_entry_value and typed DWARF stack extensions
I think, you need to wait for F17 for that.
Jakub
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Results of a test mass rebuild of rawhide/x86_64 with gcc-4.7.0-0.1.fc17
Hi!
As part of preparations to switch GCC in F17 to GCC 4.7.0, I've performed
a test mass rebuild of rawhide (December 23th package list) using
gcc-4.7.0-0.1.fc17 on x86_64, and for those packages that failed also
rebuilt the same package with gcc-4.6.2-1.fc16 to quickly remove from the
list packages that fail for non-gcc related reasons.
Out of the 11270 packages I've built, 10056 packages built fine with
gcc-4.7.0-0.1.fc17 and 845 packages failed to build also with
gcc-4.6.2-1.fc16, so I'm ignoring those from any analysis.
I've analyzed some of the remaining failures and tried to categorize it
a little bit. There were 3 internal compiler errors seen during the
whole mass rebuild, http://gcc.gnu.org/PR5169{2,4,5} are currently
filed and slightly analyzed, but not fixed yet.
CCing Benjamin if he'd be interested to write
http://gcc.gnu.org/gcc-4.7/porting_to.html again this time.
The common reasons for build failures were (I'm attaching srpm lists for
these categories):
http://gcc.gnu.org/PR49745 119 failures
iostream, string and other STL headers that previously
included unistd.h as an implementation detail (to get some
feature macros for gthr*.h purposes) no longer do so (it was
a C++ standard violation), to fix this up just add
#include unistd.h early in the sources (or headers) that need it.
http://gcc.gnu.org/PR24163 60 failures
http://gcc.gnu.org/PR29131 28 failures
C++ lookup fixes, the C++ FE no longer performs an extra unqualified
lookup that it (incorrectly) performed in the past. In some cases the
diagnostics includes hints how to fix the bugs, for PR24163 the
diagnostics looks like:
error: 'something' was not declared in this scope, and no declarations
were found by argument-dependent lookup at the point of instantiation
[-fpermissive]
note: declarations in dependent base 'someclasssomearg' are not found
by unqualified lookup
note: use 'this-something' instead
and for PR29131 diagnostics looks like:
error: 'something' was not declared in this scope, and no declarations
were found by argument-dependent lookup at the point of instantiation
[-fpermissive]
note: 'templateclass T1, class T2 sometype something(T1, const T2)'
declared here, later in the translation unit
checking for stdbool.h that conforms to C99... no 2 failures
but affects other 150+
packages
apparently autoconf 2.60 through autoconf 2.67 contains an invalid
check in its stdbool.h checking macro:
# if defined __xlc__ || defined __GNUC__
/* Catch a bug in IBM AIX xlc compiler version 6.0.0.0
reported by James Lemley on 2005-10-05; see
http://lists.gnu.org/archive/html/bug-coreutils/2005-10/msg00086.html
This test is not quite right, since xlc is allowed to
reject this program, as the initializer for xlcbug is
not one of the forms that C requires support for.
However, doing the test right would require a runtime
test, and that would make cross-compilation harder.
Let us hope that IBM fixes the xlc bug, and also adds
support for this kind of constant expression. In the
meantime, this test will reject xlc, which is OK, since
our stdbool.h substitute should suffice. We also test
this with GCC, where it should work, to detect more
quickly whether someone messes up the test in the
future. */
char digs[] = 0123456789;
int xlcbug = 1 / ((digs + 5)[-2 + (bool) 1] == digs[4] ? 1 :
-1);
# endif
As written, the test is not quite right and a conforming C compiler
is not required to accept it and starting with
http://gcc.gnu.org/viewcvs?root=gccview=revrev=172958
GCC rejects it (and similarly from what I understood from autoconf
2.68 notes recent xlc rejects it as well). autoconf 2.68 dropped
this incorrect check, but apparently many packages include their
own configure scripts without regenerating them. Wonder what is the
best thing to do here, ask package maintainers to grep for this
int xlcbug = ...; in their packages and sedding that to
int xlcbug = 0;, or dropping that || defined __GNUC__ above the
invalid test, or asking where possible to regenerate configure with
autoconf 2.68, perhaps some rpm-build script to do the sedding?
Most of the 150+ packages just refused to use the system stdbool.h
because of this and did something else (either provided their own
stdbool.h alternative, falled back to using int
Re: Results of a test mass rebuild of rawhide/x86_64 with?gcc-4.7.0-0.1.fc17
On Sat, Dec 31, 2011 at 08:55:53AM -0600, Dennis Gilmore wrote: if we plan to do a mass rebuild for gcc 4.7 we need to start it next week. IMHO a mass rebuild is highly desirable, but (with the exception of a few gcj/objc dependent packages not strictly required). We still have lots of *.fc15, and we even have some *.fc11 packages. That said, why would it need to start next week? Looking at the F15 schedule where a mass rebuild has been performed too on Feb, 7th or so, the schedule milestones are the same. I can put gcc-4.7.0-0.2.fc17 say mid next week into the buildroots, but would strongly prefer to have it there for at least two weeks of voluntary rebuilds, so that there is enough time to report bugs and get them fixed, before a real mass rebuild starts. So, if at all possible, I'd prefer the mass rebuild to start around January 19th or 20th. That's still before Feature Submission Deadline and more than three weeks before Alpha deadline. Jakub -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Results of a test mass rebuild of rawhide/x86_64 with gcc-4.7.0-0.1.fc17
On Mon, Jan 02, 2012 at 09:09:29AM -0700, Nathanael Noblet wrote: On Jan 2, 2012, at 5:30 AM, Nils Philippsen wrote: I've attached a list of packages and (co)maintainers, to easily find if one of your packages is affected or not. It seems one of my packages has an issue, the gcc unistd.h include one. How do I reproduce the build issues? Is there a package someplace or mock config I can use to test it out to make sure I have it working/patched? Do I need to use my own repos with an unsigned build of gcc from koji? Or will there be a global repo people can use prior to the mass rebuild? Or should I just wait for the mass rebuild and do it then etc?? Just wait an extra day or two. Jakub -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Results of a test mass rebuild of rawhide/x86_64 with gcc-4.7.0-0.1.fc17
On Mon, Jan 02, 2012 at 07:03:44PM +0100, Jim Meyering wrote: I have just tried to build iwhd on F16 using a pretty recent gcc-4.7.x (built manually: 4.7.0 20111202), and it worked fine, so I'm not quite sure why iwhd is on the list. Maybe the gcc-4.7.x that Jakub used lacks something that's in my Dec 2 snapshot, or maybe it's simply a problem in a dependent that has been fixed in the interim. iwhd was in the totally non-analyzed lists, which built normally in rawhide x86_64 mock and failed to build with that plus my gcc 4.7.0 + libtool repo. The failure was: checking gc.h presence... yes checking for gc.h... yes checking for mongo/client/dbclient.h... no configure: error: Missing Mongo DB client development library: mongodb-devel error: Bad exit status from /var/tmp/rpm-tmp.ndPEGn (%build) Bad exit status from /var/tmp/rpm-tmp.ndPEGn (%build) RPM build errors: Child returncode was: 1 Given the huge amount of packages, I really don't have time to look at every one, the mass rebuild was performed mainly to determine gcc 4.7 readiness and find out most common porting issues when porting from 4.6 to 4.7. The rebuilds were all done using mock, while with the same set of package NVRs (taken from 23rd SRPMS list), the rawhide distro could very well be slightly changing even over the period of the few days it took to rebuild everything. BTW, the stdbool configury problem I wrote about is solved on the gcc side, we optimize again the (not strictly valid) test and thus the standard autoconf 2.6[0-7] stdbool detection should work again. Jakub -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: GCC 4.7 build issues: error: no matching function for call...
On Mon, Jan 09, 2012 at 11:04:33AM -0600, Richard Shaw wrote: I think I'm almost there. I was also troubleshooting parallel make issues but I think I've got that sorted out (thankfully it builds with cmake). The build seems to pause for a while and I see the following output: /builddir/build/BUILD/openCOLLADA-svn864/COLLADASaxFrameworkLoader/src/generated14/COLLADASaxFWLColladaParserAutoGen14PrivateFunctionMap.cpp:20:6: note: variable tracking size limit exceeded with -fvar-tracking-assignments, retrying without Is this anything I should worry about? Is there anything I (as the packager) could/should do about it? This is just a note from the compiler the debug info for the particular function will have lower quality, because the function is too large/complex. You could raise the limit with --param=max-vartrack-size=N (the default is 5000), but you could end up with very slow compilation or the compiler could ned gigabytes of memory to compute the debug info location lists. Jakub -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Moving gnustep to clang/llvm
On Wed, Jan 18, 2012 at 06:03:05PM +0100, Jochen Schmitt wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 18.01.2012 17:57, Andrew Haley wrote: The issue was, that during thu build of gnustep-base I have got a error messag which told me, that the file objc/objc-api.h was not found. So I have ask upstream for support to solve this issue. Right, so it's probably not a gcc issue but a real bug in gnustep. The cited file objc/objc-api.h was provided by the gcc-objc package and was removed by gcc-4.7.0, so the reason for my issue depends on the gcc-4.7.0 packages. GCC 4.6 objc-api.h said: /* This file declares the traditional GNU Objective-C Runtime API. It is the API supported by older versions of the GNU Objective-C Runtime. Include this file to use it. This API is being replaced by the modern GNU Objective-C Runtime API, which is declared in objc/runtime.h. The modern API is very similar to the API used by the modern Apple/NeXT runtime. The last version of GCC supporting the traditional API is GCC 4.6. This file will not exist in later versions of GCC. Because the two APIs have some conflicting definitions (in particular, Method and Category are defined differently) you should include either objc/objc-api.h (to use the traditional GNU Objective-C Runtime API) or objc/runtime.h (to use the modern GNU Objective-C Runtime API), but not both. */ so it is surprising that gnustep maintainers didn't bother to do anything to move toward objc/runtime.h. And it surprises me that clang actually didn't remove that header too, I'd have thought that Nicola Pero removed it because it was gone in clang/llvm too. Jakub -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: gcc 4.7 changes binary behaviors ?
On Thu, Jan 26, 2012 at 07:12:43AM +, Sérgio Basto wrote: Hi, hope that also could help Has package builder we also build kBuid http://koji.fedoraproject.org/koji/packageinfo?packageID=7356 , after use kBuid compile with gcc 4.7 I got this error on building virtuaBox /usr/bin/kmk_sed: file /builddir/build/BUILD/VirtualBox-4.1.8_OSE/src/VBox/Runtime/common/err/errmsg.sed line 31: Unmatched [ or [^ kmk: *** [/builddir/build/BUILD/VirtualBox-4.1.8_OSE/obj/obj/Runtime/errmsgdata.h] Error 1 kmk: *** Deleting file `/builddir/build/BUILD/VirtualBox-4.1.8_OSE/obj/obj/Runtime/errmsgdata.h' kmk: *** Waiting for unfinished jobs build virtualbox with same kBuild but that was build with gcc 4.6 I don't have this problem using kBuild-0.1.98-1.r1.fc17 works, using kBuild-0.1.98-2.r1.fc17 I got this error, with kmk_sed. Any clue is appreciated That just clearly shows how bundling libraries (violation of Fedora packaging guidelines) is harmful. Apparently, kBuild/src/sed/lib contains a copy of sed? regex code which is a copy of the glibc code (but I hope sed is configured to use the system regex), so it hits the same problem as has been already fixed in glibc: http://sources.redhat.com/ml/libc-alpha/2011-12/msg00091.html Please file bugs against kBuild and possibly against sed too. Jakub -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: gcc 4.7 changes binary behaviors ?
On Fri, Jan 27, 2012 at 05:22:20AM +, Sérgio Basto wrote: As an illustration gcore also broke with gcc-4.7 but it was a bug of gcore: http://sourceware.org/ml/binutils/2011-12/msg00298.html as the code violates ISO C99 6.2.4 item 5 by using local variable outside of its block, GCC optimizes out the second memcpy, keeping there only that memset. well kmk_sed code not have necessary to be ISO C99, which could be a tip try compile kbuild without change behavior of gcc 4.7 My complain about bundling of libraries etc. was just a generic one, if for some particular reasons you can't stop doing that, you need to apply the patch I've referenced in my earlier mail to kBuild sources as well. It is triggering undefined behavior too, by lying to the compiler that a function is pure (a function that only uses its arguments and can read memory in order to return result, but can't modify global state) when it modifies memory. Jakub -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Apple will use LLVM
On Thu, Feb 16, 2012 at 11:12:06AM -0500, Bill Nottingham wrote: The another usual mistake when people compare speed of GCC and LLVM is to use -O2 for the both compilers. But the true is that -O1 of GCC is -O2 of LLVM with the point of code generation quality. The compiler speed of GCC with -O1 is the same as for LLVM with -O2. You can find the latest comparison of LLVM and GCC on http://vmakarov.fedorapeople.org/spec/ (see 2011 comparison at the bottom of the left frame). Speaking of potential magic bullets... is there any reason we don't enable auto-vectorization by default (with -O3, or with the assorted -f/-m flags?) Auto-vectorization is enabled by default for -O3 if the chosen CPU supports vector instructions (i.e. on x86_64 always, on i?86 only for -msse (and better -msse2, -mavx can make a big difference over -msse2 for both), or can be enabled manually (-O2 -ftree-vectorize). Enabling it by default isn't a magic bullet, I believe most of the distro code is cold code where -O3 or even -O2 -ftree-vectorize would enlarge the code size too much, increase cache footprint and not be a win in the end. For performance sensitive code sure, enabling -O3 or -O2 -ftree-vectorize is desirable, even better when acompanied by PGO (-fprofile-generate, run the resulting application on some training data (benchmark, testsuite, ...), -fprofile-use). For just -O3 or -O2 -ftree-vectorize we could perhaps have some knob in the spec files to request those extra flags, for PGO it really requires some work from the packager (but e.g. bash/grep/awk, perhaps perl/python etc. would definitely improve, gcc itself is already built with PGO). - Is it not stable enough? It is pretty stable, of course -O2 -g is the usual default, so -O3 is somewhat less tested than that, but many LFS distros are sometimes built with -O3. - Does it not take effect often enough? It takes effect pretty often and is improving in that, though of course in many cases could take effect even more often than now. On the other side the current cost model is not very precise and sometimes vectorization slows things down instead of speeding it up, sometimes on some CPUs only. Jakub -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Apple will use LLVM
On Wed, Feb 22, 2012 at 08:46:19AM +0100, Roman Rakus wrote: On 02/16/2012 05:33 PM, Jakub Jelinek wrote: For just -O3 or -O2 -ftree-vectorize we could perhaps have some knob in the spec files to request those extra flags, for PGO it really requires some work from the packager (but e.g. bash/grep/awk, perhaps perl/python etc. would definitely improve, gcc itself is already built with PGO). What kind of work? I have tried to build bash with added -O2 -ftree-vectorize -fprofile-generate, but the build fails with many undefined reference to `__gcov_*. That would be probably because -lgcov isn't linked in. When using -fprofile-generate, you need to pass that switch not just during compilation, but also when linking the binaries (or libraries) that contain -fprofile-generate compiled objects. Jakub -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Apple will use LLVM
On Thu, Feb 23, 2012 at 05:26:25PM +0100, Roman Rakus wrote: On 02/22/2012 09:08 AM, Jakub Jelinek wrote: On Wed, Feb 22, 2012 at 08:46:19AM +0100, Roman Rakus wrote: On 02/16/2012 05:33 PM, Jakub Jelinek wrote: For just -O3 or -O2 -ftree-vectorize we could perhaps have some knob in the spec files to request those extra flags, for PGO it really requires some work from the packager (but e.g. bash/grep/awk, perhaps perl/python etc. would definitely improve, gcc itself is already built with PGO). What kind of work? I have tried to build bash with added -O2 -ftree-vectorize -fprofile-generate, but the build fails with many undefined reference to `__gcov_*. That would be probably because -lgcov isn't linked in. When using -fprofile-generate, you need to pass that switch not just during compilation, but also when linking the binaries (or libraries) that contain -fprofile-generate compiled objects. Jakub Thanks. Anyone who wants to try/test such built bash can use my builds which I copied to fedorapeople [1]. It was built using mock. Any comments, test results are welcome. [1] http://rrakus.fedorapeople.org/bash-PGO/ You are compiling with 'CPPFLAGS=-D_GNU_SOURCE -DRECYCLES_PIDS -O2 -ftree-vectorize -fprofile-generate -fprofile-use' That doesn't make sense. You need to build twice. Step 1) build with -fprofile-generate (other flags the same in both builds) Step 2) run the program on some typical workload (make check, some large configure script you want to ptimize for, the closer it is to what people will use it for, the better) Step 3) make clean the *.o file, keep around the *.gcda files step 2) generated, build again, this time with -fprofile-use Jakub -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: C++ ABI rebuilds for rawhide too?
On Wed, Feb 29, 2012 at 09:38:58AM +0100, Stephan Bergmann wrote: On 02/28/2012 09:18 PM, Bruno Wolff III wrote: Are the same packages going to get automatically rebuilt in rawhide as well as f17? Btw, does anybody have a pointer to that ABI breakage in gcc 4.7 for c++ (i.e., was it an inadvertent breakage, or is there a planned incompatibility for GCC 4.7)? http://gcc.gnu.org/ml/gcc-patches/2012-02/msg01219.html During the development of GCC 4.7, one virtual method of the std::num_get template was mistakenly moved around, which meant that std::num_get vtables were ABI incompatible with GCC 4.6 and earlier. The above patch fixed that. So, the rebuilds of everything that includes the problematic bits/locale_facets.h header are now needed so that F17 isn't ABI incompatible both with GCC 4.6 and earlier as well as GCC 4.7 upstream release. We are sorry about this and are actively working on testing infrastructure that will catch any similar vtable ABI incompatibilities (the quick hack scripts to check that showed this was the only problem). Jakub -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: C++ ABI rebuilds for rawhide too?
On Wed, Feb 29, 2012 at 09:50:06AM +0100, Dan Horák wrote:
Stephan Bergmann píše v St 29. 02. 2012 v 09:38 +0100:
On 02/28/2012 09:18 PM, Bruno Wolff III wrote:
Are the same packages going to get automatically rebuilt in rawhide as
well as f17?
Btw, does anybody have a pointer to that ABI breakage in gcc 4.7 for
c++ (i.e., was it an inadvertent breakage, or is there a planned
incompatibility for GCC 4.7)?
from changelog in gcc-4.7.0-0.16.fc17
- fix vtable for std::num_getchar, std::istreambuf_iteratorchar,
std::char_traitschar and vtable for std::num_getwchar_t,
std::istreambuf_iteratorwchar_t, std::char_traitswchar_t ABI
breakage
It was definitely not intentional and we were told that the gcc team
added new tests
Haven't added yet, but they will be soon, definitely for GCC 4.8.
So far the testing was only manual, attaching script that was used for that:
(./vtable-check.sh version1/libstdc++.a /tmp/version1; ./vtable-check.sh
version2/libstdc++.a /tmp/version2; diff -upr /tmp/version{1,2})
Jakub
vtable-check.sh
Description: Bourne shell script
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Why we need redhat_lsb_trigger.c in redhat-lsb package?
On Wed, Mar 14, 2012 at 10:08:32AM +0100, Niels de Vos wrote:
On 03/13/2012 07:04 AM, Xibo Ning wrote:
The best solution would probably be to replace the %triggerpostun
with a lua scriptlet, something like this (totally untested and
you'll need to add the LSB-version somewhere too):
%triggerpostun -p lua -- glibc
LDSO = /usr/lib/ld.so
LSBLDSO = /usr/lib/ld. + LSB_VERSION + .so
%ifarch ia64
LDSO = /emul/ia32-linux/lib + LSBLDSO
%fi
posix.symlink(LDSO, LSBLDSO)
That is not equivalent. is_ia64 () is true in the statically linked
binary for %ifarch %{ix86} if running on the ia64 CPU (software emulated).
Jakub
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RFC: Primary architecture promotion requirements
On Tue, Mar 20, 2012 at 03:19:35PM +, Matthew Garrett wrote: This is very much a draft, but I'd like to start a discussion regarding what we expect from primary architectures. Feedback not only welcome, but actively desired. I think the speed of the build hardware should be also part of the criteria, as all primary architectures are built synchronously. GCC on x86_64/i686 currently builds often in 2 hours, sometimes in 4 hours if a slower or more busy box is chosen, but on ARM it regularly builds 2 days. That is a slow down factor of 12x-24x, guess for other larger packages it is similar. Jakub -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RFC: Primary architecture promotion requirements
On Tue, Mar 20, 2012 at 08:58:45AM -0700, Brendan Conoboy wrote: On 03/20/2012 08:24 AM, Jakub Jelinek wrote: I think the speed of the build hardware should be also part of the criteria, as all primary architectures are built synchronously. GCC on x86_64/i686 currently builds often in 2 hours, sometimes in 4 hours if a slower or more busy box is chosen, but on ARM it regularly builds 2 days. That is a slow down factor of 12x-24x, guess for other larger packages it is similar. Our current build systems can turn GCC 4.7 around in about 24 hours. The enterprise hardware we anticipate using will take that down to about 12 hours. If speed of build hardware is a consideration, where do you draw the line? No secondary arch is going to get to the speed of x86_64 in the foreseeable future, so it's effectively a way to keep PA an exclusive x86 club. Looking at last gcc build times (not unusual, though I really remember arm taking much longer than that, e.g. 4.7.0-0.11.fc17 took almost 17 hours on both arm architectures), from http://*koji.fedoraproject.org/packages/gcc/4.7.0/0.20.fc17/data/logs/*/state.log : i6864h18m x86_64 1h25m ppc 4h12m ppc64 4h16m s3906h27m s390x 6h04m armv5tel26h20m armv7hl 24h17m So even speeding this up twice means it is still 2x slower than the slowest other secondary architecture. I think the real question is, for the developers of on devel-list, how will longer builds for one arch than another affect your workflow? If builds on two architectures start at the same time, but one takes longer to finish than the other, how will that impact you? Right now you'll still be able to see and use the results of the faster build before the slower build completes, so are you materially impacted? For the builds completed on some architectures, but waiting on others nothing is moved over to the packages/ dirs. Yes, you can grab them from the task directories, but only manually, scripts fetching testsuite results won't see them, it can't be filed into bodhi, in rawhide isn't tagged into the buildroots, etc. Jakub -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: compat-gcc-32
On Sat, Mar 24, 2012 at 12:16:24PM -0700, Dave Close wrote: How is it possible that Fedora 16 includes package compat-gcc-32-3.2.3-debuginfo.i686.rpm but does not appear to include the underlying compat-gcc-32-3.2.3.i686.rpm? To what does the debuginfo package pertain (it says, This package provides debug information for package compat-gcc-32.)? Should I be looking somewhere other than the Fedora repositories to find it? compat-gcc-32 is the name of the src.rpm, compat-libstdc++* is the package it generates. Jakub -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: gforth and gcc 4.7
On Mon, Mar 26, 2012 at 04:54:05PM +0200, Adrian Reber wrote: Trying to build gforth with gcc 4.7 fails currently. The forth engine is build but it fails its included tests. The problem is that every newline the forth engine writes is replaced with 0x00 as seen in following diff: 010: 6566 696e 6564 2047 4458 2020 594f 5520 efined GDX YOU 020: 5348 4f55 4c44 2053 4545 2054 4845 2053 SHOULD SEE THE S 030: 5441 4e44 4152 4420 4752 4150 4849 4320 TANDARD GRAPHIC -040: 4348 4152 4143 5445 5253 3a00 2021 2223 CHARACTERS:. !# ^^ actual output +040: 4348 4152 4143 5445 5253 3a0a 2021 2223 CHARACTERS:. !# ^^ expected output 050: 2425 2627 2829 2a2b 2c2d 2e2f 3031 3233 $%'()*+,-./0123 Removing -O2 from the compiler commandline fixes it, but I have no idea why this happens. Does anyone have an idea how this can be solved? If -O0 works and -O2 doesn't, first narrow it down using a binary search between -O0 and -O2 compiled objects to at least a single compilation unit, then you could use __attribute__((optimize (0))) (resp. __attribute__((optimize (2))) ) and/or -fno-inline to narrow it even further, read the problematic code, see if there aren't any e.g. aliasing warnings (-O2 enables -fstrict-aliasing), if you don't spot a bug in the gforth code after this and still suspect the compiler, turn that into self-contained minimal testcase (for the problematic routine add main that calls it with the right arguments, make the problematic routine __attribute__((noinline, noclone)) and stub out anything it calls, then file a gcc bugreport? Jakub -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F-13 libtool broken by gcc update
On Mon, May 03, 2010 at 02:30:54PM -0400, Tom Lane wrote: F-13 builds requiring libtool are now failing with DEBUG util.py:256: libtool-2.2.6-18.fc13.x86_64 from build has depsolving problems DEBUG util.py:256:-- Missing Dependency: gcc = 4.4.3 is needed by package libtool-2.2.6-18.fc13.x86_64 (build) DEBUG util.py:256: Error: Missing Dependency: gcc = 4.4.3 is needed by package libtool-2.2.6-18.fc13.x86_64 (build) DEBUG util.py:256: You could try using --skip-broken to work around the problem apparently as a result of the fact that gcc was updated to 4.4.4 over the weekend. Could we have a fix for this ASAP, please? And why weren't there loud bleats from broken-dependencies checking? gcc-4.4.4-1.fc13 has just been tagged temporarily into dist-f13-override so that new libtool could be built. Likely you tried to built during that short window or NewRepo has been too slow after it has been untagged from dist-f13-override already. Jakub -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F-13 libtool broken by gcc update
On Mon, May 03, 2010 at 03:35:44PM -0400, Tom Lane wrote: Mamoru Tasaka mtas...@ioa.s.u-tokyo.ac.jp writes: $ TZ=UTC koji list-tag-history --build=gcc-4.4.4-1.fc13 Sat May 1 00:57:24 2010: Tagged gcc-4.4.4-1.fc13 with dist-f13-updates-candidate [still active] Mon May 3 15:58:06 2010: Tagged gcc-4.4.4-1.fc13 with dist-f13-override Mon May 3 17:37:31 2010: Untagged gcc-4.4.4-1.fc13 from dist-f13-override The dependency was broken only for this 2 hours (perhaps to rebuild libtool for gcc 4.4.4). ... Once newrepo is created, dependency will be recovered again. BTW, it's now two hours later and gcc 4.4.4 is still in the buildroot. There is no newrepo task running for F-13, and no evidence that one has been launched recently. Perhaps an untag event fails to force a repo rebuild? If so seems like a bug. So what is http://koji.fedoraproject.org/koji/taskinfo?taskID=2158992 then? Jakub -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
