https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65351
Iain Sandoe <iains at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Attachment #35174|0 |1
is obsolete| |
--- Comment #11 from Iain Sandoe <iains at gcc dot gnu.org> ---
Created attachment 35212
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35212&action=edit
minimum change
OK - So Jakub's patch works with a minor change (quote the two components) viz:
- $1=-fno-common
+ $1='-fno-common -mno-dynamic-no-pic'
1. the minimum change to fix this bug is to reconfigure libiberty with the
changed picflag.m4 (the attached patch includes the regenerated
libiberty/configure so that folks can test if they like).
-- Perhaps we should extend that to all cases where */configure.ac calls
GCC_PICFLAG (although it's not needed for this pr, it might save confusion when
someone subsequently reconfigures).
2. I investigated --enable-host-shared and this seems to be a can of worms.
- some places in the GCC tree just don't consider the possibility that the
host/target might need pic options
- most places just jam -fPIC regardless of the host.
- if I go through all of these cases and add in GCC_PICFLAG /
GCC_PICFLAG_TARGET as appropriate I can get --enable-host-shared builds to
complete on m32 darwin (but it doesn't seem like stage4 change and isn't a
regression in any case).
- Even on x86_64 linux I don't see --enable-host-shared producing any .so for
these host-side libs (it seems to just generate convenience libs with PIC
code).
- It's possible that some other places should be linking the PIC version of
libiberty (e.g. libsupc++) …
- I need to test this minimum change on a couple more boxes.
