Re: ld terminated with signal 9 [Killed]
Dan Horák píše v Čt 19. 02. 2015 v 20:12 +0100: > On Thu, 19 Feb 2015 19:51:38 +0100 > Marek Skalický wrote: > > > Hi, > > I were trying to compile f22 mongoDB package with enabled > > _hardened_build . And it always failed with: > > > > collect2: fatal error: ld terminated with signal 9 [Killed] > > compilation terminated. > > scons: *** [build/linux2/ssl/use-system-all/usev8/mongo/mongod] Error > > 1 scons: building terminated because of errors. > > RPM build errors: > > error: Bad exit status from /var/tmp/rpm-tmp.NWmAoC (%build) > > Bad exit status from /var/tmp/rpm-tmp.NWmAoC (%build) > > Child return code was: 1 > > > > (log file > > https://kojipkgs.fedoraproject.org//work/tasks/8167/8998167/build.log) > > > > I've tried it four times and compilation failed always in different > > place (linking different binaries). Without enabled hardening it > > builds fine. (On 9 Jan with a little older version I tried scratch > > hardened build and it also worked fine) > > > > Where could be problem? Is it possible, that there isn't enough > > memory? > > yes, looks as an out-of-memory situation, you can try switching to -g1 > in CFLAGS for lesser debug infos (see eg. webkitgtk4) or using -j1 for > make if there would be more jobs competing for memory > > > Dan > > PS: please send the link to the task, not to the log directly These task failed with this problem: https://koji.fedoraproject.org/koji/taskinfo?taskID=8998165 https://koji.fedoraproject.org/koji/taskinfo?taskID=8997879 https://koji.fedoraproject.org/koji/taskinfo?taskID=8995972 https://koji.fedoraproject.org/koji/taskinfo?taskID=8994536 Thanks for suggesting -g1. I will try it... Marek -- 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: [Test-Announce] Fedora 22 Branched 20150218 nightly compose nominated for testing
On Thu, 2015-02-19 at 08:38 -0600, Michael Cronenworth wrote:
> On 02/18/2015 01:21 PM, adamw...@fedoraproject.org wrote:
> >
> > https://fedoraproject.org/wiki/Test_Results:Fedora_22_Branched_20150218_Installation
> >
>
> Text-mode installation does not work - noted in the matrix.
Thanks!
Failure reports are *much* more useful, though, if you file a bug and
include a link to it. The syntax is:
{{fail|username|bug#}}
e.g.
{{fail|adamwill|1234567}}
or you can of course use relval report-results.
> The installation source spoke does not work. No matter what I
> choose, even
> specifying a repo URL, anaconda says it cannot find a valid
> installation source.
Thanks for the report, I'll take a look at that and see if I can
reproduce and figure out what's going on.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
--
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: So everything in Rawhide must be compiled with -fPIC?
I'd like to know the performance loss estimated/examined by FESCO, or I think it's a bad idea on i686 systems, it's already slow enough. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
libuv soname bump
I have just updated libuv in F22 and rawhide to the 1.x series (1.4.0 to be exact) which introduces a proper soname upstream that is bumped from the previous Fedora package. libuv currently only has two dependencies in Fedora. One dependent, moarvm, has already been rebuilt. The other, nodejs, will use the newly introduced compat-libuv010 package for the life of the Fedora 22 release. It will be updated to the new 0.12 release for F23, which can use the new libuv. This compat package will then be retired. No new packages in Fedora should depend on compat-libuv010. Please instead use the main libuv package, as many changes released in the v1.x series were focused on making the library more useful to consumers besides nodejs. Thanks, -T.C. -- 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: So everything in Rawhide must be compiled with -fPIC?
On Thu, Feb 19, 2015 at 12:34 PM, Till Maas wrote: > On Thu, Feb 19, 2015 at 08:15:19PM +0100, Jakub Jelinek wrote: > > > I've never argumented against the goal that web browser or all network > aware > > services should be PIEs, after all, why would we (Ulrich Drepper and > myself) > > add the PIE support into the toolchain otherwise? > > I'm just not convinced most of the unpriviledged programs should be PIEs. > > Thanks to e.g. e-mail about any program can be made to run untrusted > data, e.g. PDF readers, office suites, image viewers, if you open an > attachment of the respective type. Therefore it makes a sane default > IMHO. It is also something to attract users that care about security > very much to Fedora. > https://software.intel.com/en-us/blogs/2014/12/26/new-optimizations-for-x86-in-upcoming-gcc-50-32bit-pic-mode https://gcc.gnu.org/ml/gcc/2004-06/msg01956.html >From those articles, it sounds like it's a worst case 5-10% hit. I agree that's kind of annoying and a lot of my stuff doesn't even run connected to the internet, but if that 5-10% worst case hit that will usually be imperceptible can prevent my machine from being bitten by some malware that got on the network because someone plugged in a USB drive they shouldn't have, then I'm all for it. -- 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: So everything in Rawhide must be compiled with -fPIC?
On Thu, Feb 19, 2015 at 08:15:19PM +0100, Jakub Jelinek wrote: > I've never argumented against the goal that web browser or all network aware > services should be PIEs, after all, why would we (Ulrich Drepper and myself) > add the PIE support into the toolchain otherwise? > I'm just not convinced most of the unpriviledged programs should be PIEs. Thanks to e.g. e-mail about any program can be made to run untrusted data, e.g. PDF readers, office suites, image viewers, if you open an attachment of the respective type. Therefore it makes a sane default IMHO. It is also something to attract users that care about security very much to Fedora. Regards Till -- 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: So everything in Rawhide must be compiled with -fPIC?
Am 19.02.2015 um 20:15 schrieb Jakub Jelinek: On Thu, Feb 19, 2015 at 07:58:10PM +0100, Reindl Harald wrote: Am 19.02.2015 um 19:48 schrieb Till Maas: On Thu, Feb 19, 2015 at 07:07:45PM +0100, Jakub Jelinek wrote: Even on x86_64 it was quite a measurable slowdown last time I've benchmarked it, now in F22+ we might have smaller slowdown with the x86_64 copyreloc for Which packages are there that do not process untrusted data and are slowed down much? none these days don't process untrusted data and "slowed down much" needs to be defined very well and not only by a syntectitc benchmark throwing numbers around - if it is not noticeable by a user it don't exist and security was, is and always will be a compromise between user expierience in other words: leave me in piece with generic benchmarks and things faster in theory not look at the time for recovery when machines where compromised i ran all network aware services with my own build-overrides with -fstack-protector-all long before fedora considered -fstack-protector-srtong with *zero* difference for daily workloads as example I've never argumented against the goal that web browser or all network aware services should be PIEs, after all, why would we (Ulrich Drepper and myself) add the PIE support into the toolchain otherwise? I'm just not convinced most of the unpriviledged programs should be PIEs. because malware don't need root privileges to do a lot of harm on enduser machines most data is feeded to "unpriviledged programs" and i have not seen much packages the last few years without a CVE - better be safe than sorry! signature.asc Description: OpenPGP digital signature -- 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: So everything in Rawhide must be compiled with -fPIC?
On Thu, Feb 19, 2015 at 07:58:10PM +0100, Reindl Harald wrote: > > Am 19.02.2015 um 19:48 schrieb Till Maas: > >On Thu, Feb 19, 2015 at 07:07:45PM +0100, Jakub Jelinek wrote: > > > >>Even on x86_64 it was quite a measurable slowdown last time I've benchmarked > >>it, now in F22+ we might have smaller slowdown with the x86_64 copyreloc for > > > >Which packages are there that do not process untrusted data and are > >slowed down much? > > none these days don't process untrusted data and "slowed down much" needs to > be defined very well and not only by a syntectitc benchmark throwing numbers > around - if it is not noticeable by a user it don't exist and security was, > is and always will be a compromise between user expierience > > in other words: leave me in piece with generic benchmarks and things faster > in theory not look at the time for recovery when machines where compromised > > i ran all network aware services with my own build-overrides with > -fstack-protector-all long before fedora considered -fstack-protector-srtong > with *zero* difference for daily workloads as example I've never argumented against the goal that web browser or all network aware services should be PIEs, after all, why would we (Ulrich Drepper and myself) add the PIE support into the toolchain otherwise? I'm just not convinced most of the unpriviledged programs should be PIEs. 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: ld terminated with signal 9 [Killed]
On Thu, 19 Feb 2015 19:51:38 +0100 Marek Skalický wrote: > Hi, > I were trying to compile f22 mongoDB package with enabled > _hardened_build . And it always failed with: > > collect2: fatal error: ld terminated with signal 9 [Killed] > compilation terminated. > scons: *** [build/linux2/ssl/use-system-all/usev8/mongo/mongod] Error > 1 scons: building terminated because of errors. > RPM build errors: > error: Bad exit status from /var/tmp/rpm-tmp.NWmAoC (%build) > Bad exit status from /var/tmp/rpm-tmp.NWmAoC (%build) > Child return code was: 1 > > (log file > https://kojipkgs.fedoraproject.org//work/tasks/8167/8998167/build.log) > > I've tried it four times and compilation failed always in different > place (linking different binaries). Without enabled hardening it > builds fine. (On 9 Jan with a little older version I tried scratch > hardened build and it also worked fine) > > Where could be problem? Is it possible, that there isn't enough > memory? yes, looks as an out-of-memory situation, you can try switching to -g1 in CFLAGS for lesser debug infos (see eg. webkitgtk4) or using -j1 for make if there would be more jobs competing for memory Dan PS: please send the link to the task, not to the log directly -- 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: So everything in Rawhide must be compiled with -fPIC?
On Thu, Feb 19, 2015 at 07:48:30PM +0100, Till Maas wrote: > On Thu, Feb 19, 2015 at 07:07:45PM +0100, Jakub Jelinek wrote: > > > Even on x86_64 it was quite a measurable slowdown last time I've benchmarked > > it, now in F22+ we might have smaller slowdown with the x86_64 copyreloc for > > Which packages are there that do not process untrusted data and are > slowed down much? Well, IMHO it should be the proponents of the change to show that it isn't significant. As an example I've given gcc. 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: So everything in Rawhide must be compiled with -fPIC?
Am 19.02.2015 um 19:48 schrieb Till Maas: On Thu, Feb 19, 2015 at 07:07:45PM +0100, Jakub Jelinek wrote: Even on x86_64 it was quite a measurable slowdown last time I've benchmarked it, now in F22+ we might have smaller slowdown with the x86_64 copyreloc for Which packages are there that do not process untrusted data and are slowed down much? none these days don't process untrusted data and "slowed down much" needs to be defined very well and not only by a syntectitc benchmark throwing numbers around - if it is not noticeable by a user it don't exist and security was, is and always will be a compromise between user expierience in other words: leave me in piece with generic benchmarks and things faster in theory not look at the time for recovery when machines where compromised i ran all network aware services with my own build-overrides with -fstack-protector-all long before fedora considered -fstack-protector-srtong with *zero* difference for daily workloads as example these days one simple rule: if you can improve security *than do it* signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
ld terminated with signal 9 [Killed]
Hi, I were trying to compile f22 mongoDB package with enabled _hardened_build . And it always failed with: collect2: fatal error: ld terminated with signal 9 [Killed] compilation terminated. scons: *** [build/linux2/ssl/use-system-all/usev8/mongo/mongod] Error 1 scons: building terminated because of errors. RPM build errors: error: Bad exit status from /var/tmp/rpm-tmp.NWmAoC (%build) Bad exit status from /var/tmp/rpm-tmp.NWmAoC (%build) Child return code was: 1 (log file https://kojipkgs.fedoraproject.org//work/tasks/8167/8998167/build.log) I've tried it four times and compilation failed always in different place (linking different binaries). Without enabled hardening it builds fine. (On 9 Jan with a little older version I tried scratch hardened build and it also worked fine) Where could be problem? Is it possible, that there isn't enough memory? Thanks, M. -- 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: So everything in Rawhide must be compiled with -fPIC?
On Thu, Feb 19, 2015 at 07:07:45PM +0100, Jakub Jelinek wrote: > Even on x86_64 it was quite a measurable slowdown last time I've benchmarked > it, now in F22+ we might have smaller slowdown with the x86_64 copyreloc for Which packages are there that do not process untrusted data and are slowed down much? Regards Till -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Minutes from Env-and-Stacks WG meeting (2015-02-19)
== #fedora-meeting-2: Env and Stacks (2015-02-19) == Meeting started by hhorak at 18:02:53 UTC. The full logs are available at http://meetbot.fedoraproject.org/fedora-meeting-2/2015-02-19/env-and-stacks.2015-02-19-18.02.log.html . Meeting summary --- * Follow-ups -- any changes from last week? (hhorak, 18:09:10) * Dockerfiles recommended tips (hhorak, 18:15:21) * LINK: https://fedoraproject.org/wiki/Env_and_Stacks/Tasklist (hhorak, 18:15:45) * LINK: https://fedoraproject.org/wiki/User:Hhorak/Draft/task-dockerfile-rules (hhorak, 18:15:55) * ACTION: phracek to get in touch with marek, author of JBoss Docker images best practices (hhorak, 18:24:10) * Some info about beaker @ fedoraproject and potential Env&Stack use cases (hhorak, 18:24:39) * LINK: http://beaker.fedoraproject.org/ (hhorak, 18:25:28) * The initial use case was to run installer tests in http://beaker.fedoraproject.org/ (hhorak, 18:27:44) * LINK: https://bitbucket.org/fedoraqa/fedora-beaker-tests (hhorak, 18:27:54) * Open Floor (hhorak, 18:40:48) * RpmOstree change was approved, hooray! (hhorak, 18:47:09) * LINK: https://fedoraproject.org/wiki/Changes/RpmOstree (hhorak, 18:47:09) Meeting ended at 18:48:17 UTC. Action Items * phracek to get in touch with marek, author of JBoss Docker images best practices Action Items, by person --- * phracek * phracek to get in touch with marek, author of JBoss Docker images best practices * **UNASSIGNED** * (none) People Present (lines said) --- * hhorak (53) * phracek (16) * walters (12) * zodbot (4) * bkabrda (0) * ttomecek (0) * sicampbell (0) * vpavlin (0) * juhp (0) * ncoghlan (0) Generated by `MeetBot`_ 0.1.4 .. _`MeetBot`: http://wiki.debian.org/MeetBot -- 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: So everything in Rawhide must be compiled with -fPIC?
On Thu, Feb 19, 2015 at 01:02:29PM -0500, Adam Jackson wrote: > On Thu, 2015-02-19 at 18:05 +0100, Jakub Jelinek wrote: > > On Thu, Feb 19, 2015 at 06:00:41PM +0100, Till Maas wrote: > > > I plan to change this to 1 now in Rawhide for the upcoming Fedora 23 > > > feature: > > > https://bugzilla.redhat.com/show_bug.cgi?id=1192183 > > > > > > Since I did not get any feedback from the redhat-rpm-config maintainers > > > on the bug, do you want to comment on the change? > > > > I'm opposed to that change and have said that multiple times, but if FESCO > > ruled on this already, I guess I have to give up. > > Nothing's forever, it can always be changed back. At some level I had > difficulty caring about the issue since amd64 is effectively already all > PIC anyway. Is there a reason to not want it beyond losing a register > on an already broken ABI? Even on x86_64 it was quite a measurable slowdown last time I've benchmarked it, now in F22+ we might have smaller slowdown with the x86_64 copyreloc for PIE stuff, but it hasn't been benchmarked yet. The PIC register isn't the only reason for slow down, got accesses are another, relative relocations that COW lots of pages another, instruction sizes (%rip) vs. non-PC relative another. On i?86 the slowdown is of course much more significant, then we have various other arches like arm, aarch64, ... where we probably don't have benchmark data. And x86_64 is right now the only target with copyreloc for PIEs, so all the other arches get the additional hit of plenty got dereferences everywhere. 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: So everything in Rawhide must be compiled with -fPIC?
On Thu, 2015-02-19 at 18:05 +0100, Jakub Jelinek wrote: > On Thu, Feb 19, 2015 at 06:00:41PM +0100, Till Maas wrote: > > I plan to change this to 1 now in Rawhide for the upcoming Fedora 23 > > feature: > > https://bugzilla.redhat.com/show_bug.cgi?id=1192183 > > > > Since I did not get any feedback from the redhat-rpm-config maintainers > > on the bug, do you want to comment on the change? > > I'm opposed to that change and have said that multiple times, but if FESCO > ruled on this already, I guess I have to give up. Nothing's forever, it can always be changed back. At some level I had difficulty caring about the issue since amd64 is effectively already all PIC anyway. Is there a reason to not want it beyond losing a register on an already broken ABI? - ajax -- 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: So everything in Rawhide must be compiled with -fPIC?
On Thu, Feb 19, 2015 at 06:00:41PM +0100, Till Maas wrote:
> On Thu, Feb 19, 2015 at 10:42:02AM +0100, Jakub Jelinek wrote:
> > On Thu, Feb 19, 2015 at 09:37:16AM +, Richard W.M. Jones wrote:
> > > The thing is, I'm not adding -specs=/usr/lib/rpm/redhat/redhat-hardened-ld
> > > explicitly in the real program. It's being added to everything by
> > > something in RPM. I'm not exactly sure what, maybe %{configure}?
> > >
> > > So I don't know how to control this behaviour in a real autotools-using
> > > program.
> >
> > I admit I haven't looked at rawhide redhat-rpm-config, perhaps somebody
> > broke something, but usually there is:
> > %_hardening_cflags -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1
> > # we don't escape symbols '~', '"', etc. so be careful when changing this
> > %_hardening_ldflags -specs=/usr/lib/rpm/redhat/redhat-hardened-ld
> >
> > #_hardened_build0
>
> I plan to change this to 1 now in Rawhide for the upcoming Fedora 23
> feature:
> https://bugzilla.redhat.com/show_bug.cgi?id=1192183
>
> Since I did not get any feedback from the redhat-rpm-config maintainers
> on the bug, do you want to comment on the change?
I'm opposed to that change and have said that multiple times, but if FESCO
ruled on this already, I guess I have to give up.
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: So everything in Rawhide must be compiled with -fPIC?
On Thu, Feb 19, 2015 at 10:42:02AM +0100, Jakub Jelinek wrote:
> On Thu, Feb 19, 2015 at 09:37:16AM +, Richard W.M. Jones wrote:
> > The thing is, I'm not adding -specs=/usr/lib/rpm/redhat/redhat-hardened-ld
> > explicitly in the real program. It's being added to everything by
> > something in RPM. I'm not exactly sure what, maybe %{configure}?
> >
> > So I don't know how to control this behaviour in a real autotools-using
> > program.
>
> I admit I haven't looked at rawhide redhat-rpm-config, perhaps somebody
> broke something, but usually there is:
> %_hardening_cflags -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1
> # we don't escape symbols '~', '"', etc. so be careful when changing this
> %_hardening_ldflags -specs=/usr/lib/rpm/redhat/redhat-hardened-ld
>
> #_hardened_build0
I plan to change this to 1 now in Rawhide for the upcoming Fedora 23
feature:
https://bugzilla.redhat.com/show_bug.cgi?id=1192183
Since I did not get any feedback from the redhat-rpm-config maintainers
on the bug, do you want to comment on the change?
Regards
Till
--
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: How to install Rawhide?
On Wed, 18 Feb 2015 22:24:47 -0800, Adam Williamson wrote: > Today's - 2015-02-18 - F22 nightlies seem not to have any anaconda > showstoppers, so for now probably using one of them is the best way to > install F22. Thanks! Fetched it. Also the -02-18 one for Rawhide x86_64 Live Workstation, which started fine and managed to install, too. Haven't rebooted yet, though. Somewhat odd, something was causing lots of CPU+fan usage during install, and whenever I switched to vc and fired up "top", polkitd was at the top and disappeared quickly, and the fans slowed down again. The check for weak passwords was a pain, btw. ;-) Oh, the irony, that I had to download ISO images multiple times before I could manage to install something - instead of being able to use "fedup". -- 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: Easiest way to debug build failures on rawhide?
On Wed, Feb 18, 2015 at 9:54 AM, Marcin Juszkiewicz wrote: > On 18.02.2015 16:31, Miroslav Suchý wrote: > > On 02/18/2015 04:12 PM, Dave Johansen wrote: > >> I'm running into an issue where odb won't build on rawhide ( > http://koji.fedoraproject.org/koji/taskinfo?taskID=8966447 > >> ) and I need to be able to take a look at the config.log file but it's > not available from the standard koji output. > >> > >> So what's the easiest way for me to get access to that file? Do I have > to install rawhide in a virtual machine and do > >> the build myself? Or is there a simpler way to get access to other > outputs from a build? > > > > mock -r fedora-rawhide-x86_64 --no-cleanup-after your.src.rpm > > > > and then investigate > > /var/lib/mock/fedora-rawhide-x86_64/root/builddir/build/BUILD/ > > > > or > > mock -r fedora-rawhide-x86_64 --shell > > and you are inside of that build chroot. > > For such situations I have simple script: > > - > #!/bin/bash > > SRCRPM=$1 > > X=X > LC_ALL=C LANG=C mock $SRCRPM \ > --resultdir=~mjuszkie/rpmbuild/mock/`basename $SRCRPM` \ > --verbose \ > --no-cleanup-after \ > --uniqueext=$SRCRPM $2 && X=Y > > if [ $X == X ]; then > echo "" > mock --shell --uniqueext=$SRCRPM $2 > fi > > mock --clean --uniqueext=$SRCRPM $2 > > - > > Use is simple: "hrwmock.sh *.src.rpm" (to change build target I just add > "-r fedora-21-aarch64"). > Using mock did the trick. Thanks, Dave -- 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: Easiest way to debug build failures on rawhide?
On Wed, Feb 18, 2015 at 8:36 AM, Paul Howarth wrote:
> On 18/02/15 15:12, Dave Johansen wrote:
>
>> I'm running into an issue where odb won't build on rawhide (
>> http://koji.fedoraproject.org/koji/taskinfo?taskID=8966447 ) and I need
>> to be able to take a look at the config.log file but it's not available
>> from the standard koji output.
>>
>> So what's the easiest way for me to get access to that file? Do I have
>> to install rawhide in a virtual machine and do the build myself? Or is
>> there a simpler way to get access to other outputs from a build?
>>
>
> Try something like this:
>
> %{configure} || { cat config.log ; exit 1 }
>
> The config.log content would then appear in build.log
>
That's a nifty trick that I'll definitely keep in my back pocket.
Thanks,
Dave
--
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: Results of a test mass rebuild of rawhide/x86_64 with gcc-5.0.0-0.5.fc22
On Thu, Feb 19, 2015 at 04:12:43PM +0100, Frantisek Kluknavsky wrote: > a list of things that usually break with each new gcc (like fortran modules) > would be nice to avoid a lot of pain with debugging. Does it already exist? > > WxGTK keeps a string WX_BUILD_OPTIONS_SIGNATURE currently saying "2.8 (no > debug,Unicode,compiler with C++ ABI 1002,wx containers,compatible with > 2.4,compatible with 2.6)" and it is checked at runtime. C++ ABI is supposed > to be unchanged in Fedora 22. This string changed anyway because > __GXX_ABI_VERSION in gcc changed. Is this expected/correct? Each freshly > rebuilt wx application will crash now. After wxGTK is rebuilt, each old > application will crash. A provenpackager should probably step in. That is a WxGTK bug. __GXX_ABI_VERSION can change, but usually the result is still ABI compatible, g++ emits just some aliases when mangling has changed. 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: Results of a test mass rebuild of rawhide/x86_64 with gcc-5.0.0-0.5.fc22
Hi, a list of things that usually break with each new gcc (like fortran modules) would be nice to avoid a lot of pain with debugging. Does it already exist? WxGTK keeps a string WX_BUILD_OPTIONS_SIGNATURE currently saying "2.8 (no debug,Unicode,compiler with C++ ABI 1002,wx containers,compatible with 2.4,compatible with 2.6)" and it is checked at runtime. C++ ABI is supposed to be unchanged in Fedora 22. This string changed anyway because __GXX_ABI_VERSION in gcc changed. Is this expected/correct? Each freshly rebuilt wx application will crash now. After wxGTK is rebuilt, each old application will crash. A provenpackager should probably step in. Have a nice day, Fero -- 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: [Test-Announce] Fedora 22 Branched 20150218 nightly compose nominated for testing
On 02/18/2015 01:21 PM, adamw...@fedoraproject.org wrote: https://fedoraproject.org/wiki/Test_Results:Fedora_22_Branched_20150218_Installation Text-mode installation does not work - noted in the matrix. The installation source spoke does not work. No matter what I choose, even specifying a repo URL, anaconda says it cannot find a valid installation source. I'm not a normal tester of Fedora n+1 so I cannot say when this broke. -- 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: So everything in Rawhide must be compiled with -fPIC?
On Thu, Feb 19, 2015 at 11:45:01AM +0100, Jakub Jelinek wrote:
> On Thu, Feb 19, 2015 at 10:37:46AM +, Richard W.M. Jones wrote:
> > On Thu, Feb 19, 2015 at 11:35:17AM +0100, Jakub Jelinek wrote:
> > > On Thu, Feb 19, 2015 at 10:30:50AM +, Richard W.M. Jones wrote:
> > > > info gcc, of course yes. -DPIC is not documented at all, and the
> > > > various pie/pic options are obscure to say the least.
> > >
> > > Why should -DPIC be documented? -D is documented. -DPIC means define
> > > macro PIC to 1. There is no magic in that beyond, just a convention,
> > > used e.g. by libtool, so that some sources can do things conditional on
> > > whether they are compiled as position independent or not. Of course, gcc
> > > also predefines __pic__/__PIC__/__pie__/__PIE__ macros depending on
> > > command
> > > line options.
> >
> > Can I ask you a simple question? Which of:
> >
> > -DPIE
> > -fPIE
> > -fpie
> >
> > should I use when compiling and/or linking binaries for Rawhide?
>
> It depends. If you want to compile/link position independent binaries,
> use -fpie (-fPIE if you get linker errors on certain architectures if your
> binaries are too big) to compile and -pie to link.
> If you want normal binaries, no specific options in either case.
> If you want to follow the redhat-rpm-config %_hardened_build, i.e. build
> PIEs if it is 1 and normal binaries if it is 0, make sure you pass
> %{optflags} aka $RPM_OPT_FLAGS to the compiler driver when compiling and
> %{__global_ldflags} to the compiler driver when linking.
> Overriding CFLAGS/CXXFLAGS globally to -fpie or -fPIE and LDFLAGS to -pie
> if your package builds both binaries and shared libraries won't really work,
> because you might end up compiling shared library objects with -fpie rather
> than -fpic or try to link shared libraries with -shared -pie.
Thanks - I have linked this post to the BZ and closed it.
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
libguestfs lets you edit virtual machines. Supports shell scripting,
bindings from many languages. http://libguestfs.org
--
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: So everything in Rawhide must be compiled with -fPIC?
On Thu, Feb 19, 2015 at 10:37:46AM +, Richard W.M. Jones wrote:
> On Thu, Feb 19, 2015 at 11:35:17AM +0100, Jakub Jelinek wrote:
> > On Thu, Feb 19, 2015 at 10:30:50AM +, Richard W.M. Jones wrote:
> > > info gcc, of course yes. -DPIC is not documented at all, and the
> > > various pie/pic options are obscure to say the least.
> >
> > Why should -DPIC be documented? -D is documented. -DPIC means define
> > macro PIC to 1. There is no magic in that beyond, just a convention,
> > used e.g. by libtool, so that some sources can do things conditional on
> > whether they are compiled as position independent or not. Of course, gcc
> > also predefines __pic__/__PIC__/__pie__/__PIE__ macros depending on command
> > line options.
>
> Can I ask you a simple question? Which of:
>
> -DPIE
> -fPIE
> -fpie
>
> should I use when compiling and/or linking binaries for Rawhide?
It depends. If you want to compile/link position independent binaries,
use -fpie (-fPIE if you get linker errors on certain architectures if your
binaries are too big) to compile and -pie to link.
If you want normal binaries, no specific options in either case.
If you want to follow the redhat-rpm-config %_hardened_build, i.e. build
PIEs if it is 1 and normal binaries if it is 0, make sure you pass
%{optflags} aka $RPM_OPT_FLAGS to the compiler driver when compiling and
%{__global_ldflags} to the compiler driver when linking.
Overriding CFLAGS/CXXFLAGS globally to -fpie or -fPIE and LDFLAGS to -pie
if your package builds both binaries and shared libraries won't really work,
because you might end up compiling shared library objects with -fpie rather
than -fpic or try to link shared libraries with -shared -pie.
I haven't seen any recent redhat-rpm-config change in koji though.
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: So everything in Rawhide must be compiled with -fPIC?
On Thu, Feb 19, 2015 at 10:37:46AM +, Richard W.M. Jones wrote:
> On Thu, Feb 19, 2015 at 11:35:17AM +0100, Jakub Jelinek wrote:
> > On Thu, Feb 19, 2015 at 10:30:50AM +, Richard W.M. Jones wrote:
> > > info gcc, of course yes. -DPIC is not documented at all, and the
> > > various pie/pic options are obscure to say the least.
> >
> > Why should -DPIC be documented? -D is documented. -DPIC means define
> > macro PIC to 1. There is no magic in that beyond, just a convention,
> > used e.g. by libtool, so that some sources can do things conditional on
> > whether they are compiled as position independent or not. Of course, gcc
> > also predefines __pic__/__PIC__/__pie__/__PIE__ macros depending on command
> > line options.
>
> Can I ask you a simple question? Which of:
>
> -DPIE
> -fPIE
> -fpie
Missed one:
-pie
Reading the thread that Padraig pointed to, it seems as if
_hardened_build should be adding the right flags already. It looks as
if the packager should not need to add flags at all (they would be
added automatically by %{configure}). So a second question would be,
why doesn't it?
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-builder quickly builds VMs from scratch
http://libguestfs.org/virt-builder.1.html
--
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: So everything in Rawhide must be compiled with -fPIC?
On Thu, Feb 19, 2015 at 11:35:17AM +0100, Jakub Jelinek wrote: > On Thu, Feb 19, 2015 at 10:30:50AM +, Richard W.M. Jones wrote: > > info gcc, of course yes. -DPIC is not documented at all, and the > > various pie/pic options are obscure to say the least. > > Why should -DPIC be documented? -D is documented. -DPIC means define > macro PIC to 1. There is no magic in that beyond, just a convention, > used e.g. by libtool, so that some sources can do things conditional on > whether they are compiled as position independent or not. Of course, gcc > also predefines __pic__/__PIC__/__pie__/__PIE__ macros depending on command > line options. Can I ask you a simple question? Which of: -DPIE -fPIE -fpie should I use when compiling and/or linking binaries for Rawhide? Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-p2v converts physical machines to virtual machines. Boot with a live CD or over the network (PXE) and turn machines into KVM guests. http://libguestfs.org/virt-v2v -- 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: So everything in Rawhide must be compiled with -fPIC?
On Thu, Feb 19, 2015 at 10:30:50AM +, Richard W.M. Jones wrote: > info gcc, of course yes. -DPIC is not documented at all, and the > various pie/pic options are obscure to say the least. Why should -DPIC be documented? -D is documented. -DPIC means define macro PIC to 1. There is no magic in that beyond, just a convention, used e.g. by libtool, so that some sources can do things conditional on whether they are compiled as position independent or not. Of course, gcc also predefines __pic__/__PIC__/__pie__/__PIE__ macros depending on command line options. 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: So everything in Rawhide must be compiled with -fPIC?
On Thu, Feb 19, 2015 at 11:23:18AM +0100, Jakub Jelinek wrote:
> On Thu, Feb 19, 2015 at 10:11:07AM +, Richard W.M. Jones wrote:
> >
> > I'm still no closer to being able to fix the problem.
> >
> > I have to add -fPIE (or is that -pie or -fpie or -DPIE) to every
> > executable? Upstream? Will that break on some platforms/architectures?
>
> It really should be just about using the %{optflags} and
> %{__global_ldflags} consistently, unless somebody introduced recently a
> redhat-rpm-config bug.
>
> > And indeed what is the difference between -fPIE / -pie / -fpie /
> > -fPIC / -fpic / -DPIC / etc? Where is this stuff documented?
>
> Have you tried something so obvious as man gcc ?
info gcc, of course yes. -DPIC is not documented at all, and the
various pie/pic options are obscure to say the least.
The GCC 5 documentation is not online, but here is what
GCC 4.9.2 has to say:
https://gcc.gnu.org/onlinedocs/gcc-4.9.2/gcc/Code-Gen-Options.html#Code-Gen-Options#index-PIC-2613
I've written compilers (two of them, from scratch) and this stuff
barely makes sense.
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-builder quickly builds VMs from scratch
http://libguestfs.org/virt-builder.1.html
--
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: So everything in Rawhide must be compiled with -fPIC?
On Thu, Feb 19, 2015 at 10:11:07AM +, Richard W.M. Jones wrote:
>
> I'm still no closer to being able to fix the problem.
>
> I have to add -fPIE (or is that -pie or -fpie or -DPIE) to every
> executable? Upstream? Will that break on some platforms/architectures?
It really should be just about using the %{optflags} and
%{__global_ldflags} consistently, unless somebody introduced recently a
redhat-rpm-config bug.
> And indeed what is the difference between -fPIE / -pie / -fpie /
> -fPIC / -fpic / -DPIC / etc? Where is this stuff documented?
Have you tried something so obvious as man gcc ?
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: So everything in Rawhide must be compiled with -fPIC?
I'm still no closer to being able to fix the problem. I have to add -fPIE (or is that -pie or -fpie or -DPIE) to every executable? Upstream? Will that break on some platforms/architectures? And indeed what is the difference between -fPIE / -pie / -fpie / -fPIC / -fpic / -DPIC / etc? Where is this stuff documented? Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://people.redhat.com/~rjones/virt-top -- 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: So everything in Rawhide must be compiled with -fPIC?
On Thu, Feb 19, 2015 at 09:51:33AM +, Richard W.M. Jones wrote: > There is definitely new/different behaviour in Rawhide, and recently. > > Also I was only able to see the new behaviour by updating from gcc 4.x > -> gcc 5. ie. Updating redhat-rpm-config isn't what causes the > problem. Well, gcc 4.x (or gcc 5 configured against any linker but very recent one) on x86_64 sometimes used to tollerate incorrect linking of -fpie/-fPIE compiled objects into shared libraries (it would still assume in optimizations that local definitions can't be interposed, but if you weren't trying to do that, perhaps it would happen to work). gcc 5 on x86_64 configured against recent linker assumes PIEs can use copy relocations and therefore you can get various linker errors if you try to link -fpie/-fPIE compiled objects into shared libraries. Don't do that. 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: So everything in Rawhide must be compiled with -fPIC?
On Thu, Feb 19, 2015 at 10:42:02AM +0100, Jakub Jelinek wrote:
> On Thu, Feb 19, 2015 at 09:37:16AM +, Richard W.M. Jones wrote:
> > The thing is, I'm not adding -specs=/usr/lib/rpm/redhat/redhat-hardened-ld
> > explicitly in the real program. It's being added to everything by
> > something in RPM. I'm not exactly sure what, maybe %{configure}?
> >
> > So I don't know how to control this behaviour in a real autotools-using
> > program.
>
> I admit I haven't looked at rawhide redhat-rpm-config, perhaps somebody
> broke something, but usually there is:
> %_hardening_cflags -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1
> # we don't escape symbols '~', '"', etc. so be careful when changing this
> %_hardening_ldflags -specs=/usr/lib/rpm/redhat/redhat-hardened-ld
>
> #_hardened_build0
> %_hardened_cflags %{?_hardened_build:%{_hardening_cflags}}
> %_hardened_ldflags %{?_hardened_build:%{_hardening_ldflags}}
>
> %__global_cflags-O2 -g -pipe -Wall -Werror=format-security
> -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong
> --param=ssp-buffer-size=4 -grecord-gcc-switches %{_hardened_cflags}
> %__global_ldflags -Wl,-z,relro %{_hardened_ldflags}
>
> and thus e.g. %{configure} should add the *-hardened-cc1 to
> CFLAGS/CXXFLAGS/FFLAGS etc. and *-hardened-ld to LDFLAGS.
There is definitely new/different behaviour in Rawhide, and recently.
Also I was only able to see the new behaviour by updating from gcc 4.x
-> gcc 5. ie. Updating redhat-rpm-config isn't what causes the
problem.
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-builder quickly builds VMs from scratch
http://libguestfs.org/virt-builder.1.html
--
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: So everything in Rawhide must be compiled with -fPIC?
On Thu, Feb 19, 2015 at 09:37:16AM +, Richard W.M. Jones wrote:
> The thing is, I'm not adding -specs=/usr/lib/rpm/redhat/redhat-hardened-ld
> explicitly in the real program. It's being added to everything by
> something in RPM. I'm not exactly sure what, maybe %{configure}?
>
> So I don't know how to control this behaviour in a real autotools-using
> program.
I admit I haven't looked at rawhide redhat-rpm-config, perhaps somebody
broke something, but usually there is:
%_hardening_cflags -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1
# we don't escape symbols '~', '"', etc. so be careful when changing this
%_hardening_ldflags -specs=/usr/lib/rpm/redhat/redhat-hardened-ld
#_hardened_build0
%_hardened_cflags %{?_hardened_build:%{_hardening_cflags}}
%_hardened_ldflags %{?_hardened_build:%{_hardening_ldflags}}
%__global_cflags-O2 -g -pipe -Wall -Werror=format-security
-Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong
--param=ssp-buffer-size=4 -grecord-gcc-switches %{_hardened_cflags}
%__global_ldflags -Wl,-z,relro %{_hardened_ldflags}
and thus e.g. %{configure} should add the *-hardened-cc1 to
CFLAGS/CXXFLAGS/FFLAGS etc. and *-hardened-ld to LDFLAGS.
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: So everything in Rawhide must be compiled with -fPIC?
And in another case I had (qemu), it's not predictable. If you just compile part of qemu twice, the first time it gives the error and the second time not. I had to add this hack to qemu.spec: http://pkgs.fedoraproject.org/cgit/qemu.git/commit/?id=6c3741c2769a21542a34716fa9188e520887a803 Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-builder quickly builds VMs from scratch http://libguestfs.org/virt-builder.1.html -- 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: So everything in Rawhide must be compiled with -fPIC?
On Thu, Feb 19, 2015 at 10:22:03AM +0100, Jakub Jelinek wrote:
> On Thu, Feb 19, 2015 at 09:14:32AM +, Richard W.M. Jones wrote:
> >
> > https://bugzilla.redhat.com/show_bug.cgi?id=1194167
> >
> > Basically everything in Rawhide which uses the normal RPM
> > opt flags will now have to be compiled with -fPIC, otherwise
> > you get errors like:
> >
> > /usr/bin/ld: /tmp/ccqyK5ia.o: relocation R_X86_64_32S against
> > `virConnectOpen' can not be used when making a shared object; recompile
> > with -fPIC
> >
> > This is somewhat surprising ..
>
> Of course not. But, anything you link with
> -specs=/usr/lib/rpm/redhat/redhat-hardened-ld
> has to be compiled with
> -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1
> The latter will supply -fPIE by default if you don't specify
> -fno-pic/-fpic/-fPIC/-fpie/-fPIE explicitly on the command line,
> similarly to how redhat-hardened-ld supplies -pie if -shared is not given.
> The rule is simple, objects to be linked into shared libraries
> have to be compiled with -fpic or -fPIC.
> Objects linked into position independent binaries have to be compiled
> with -fpie or -fPIE or -fpic or -fPIC (the latter two being less efficient
> for PIEs, on the other side can be linked into shared libraries too).
> Objects linked into position dependent binaries can be compiled with any of
> -fno-pic/-fpic/-fPIC/-fpie/-fPIE (-fno-pic is the default if you don't use
> -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 and is the most efficient
> -flag for position dependent binaries).
The thing is, I'm not adding -specs=/usr/lib/rpm/redhat/redhat-hardened-ld
explicitly in the real program. It's being added to everything by
something in RPM. I'm not exactly sure what, maybe %{configure}?
So I don't know how to control this behaviour in a real autotools-using
program.
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-builder quickly builds VMs from scratch
http://libguestfs.org/virt-builder.1.html
--
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: So everything in Rawhide must be compiled with -fPIC?
On Thu, Feb 19, 2015 at 09:14:32AM +, Richard W.M. Jones wrote: > > https://bugzilla.redhat.com/show_bug.cgi?id=1194167 > > Basically everything in Rawhide which uses the normal RPM > opt flags will now have to be compiled with -fPIC, otherwise > you get errors like: > > /usr/bin/ld: /tmp/ccqyK5ia.o: relocation R_X86_64_32S against > `virConnectOpen' can not be used when making a shared object; recompile with > -fPIC > > This is somewhat surprising .. Of course not. But, anything you link with -specs=/usr/lib/rpm/redhat/redhat-hardened-ld has to be compiled with -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 The latter will supply -fPIE by default if you don't specify -fno-pic/-fpic/-fPIC/-fpie/-fPIE explicitly on the command line, similarly to how redhat-hardened-ld supplies -pie if -shared is not given. The rule is simple, objects to be linked into shared libraries have to be compiled with -fpic or -fPIC. Objects linked into position independent binaries have to be compiled with -fpie or -fPIE or -fpic or -fPIC (the latter two being less efficient for PIEs, on the other side can be linked into shared libraries too). Objects linked into position dependent binaries can be compiled with any of -fno-pic/-fpic/-fPIC/-fpie/-fPIE (-fno-pic is the default if you don't use -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 and is the most efficient -flag for position dependent binaries). 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
So everything in Rawhide must be compiled with -fPIC?
https://bugzilla.redhat.com/show_bug.cgi?id=1194167 Basically everything in Rawhide which uses the normal RPM opt flags will now have to be compiled with -fPIC, otherwise you get errors like: /usr/bin/ld: /tmp/ccqyK5ia.o: relocation R_X86_64_32S against `virConnectOpen' can not be used when making a shared object; recompile with -fPIC This is somewhat surprising .. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://people.redhat.com/~rjones/virt-top -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
