Bug 832545

Hello,

could you test this build please?
http://koji.fedoraproject.org/koji/taskinfo?taskID=4342268

Thanks,

peter

For the life of me, I cannot remember what I was compiling at the time to generate this error, but the build logs look good.

Thanks for check.

Fixed in:
zlib-1.2.7-5.fc18
http://koji.fedoraproject.org/koji/buildinfo?buildID=345453

zlib-1.2.5-7.fc17 has been submitted as an update for Fedora 17.
https://admin.fedoraproject.org/updates/zlib-1.2.5-7.fc17

zlib-1.2.5-7.fc16 has been submitted as an update for Fedora 16.
https://admin.fedoraproject.org/updates/zlib-1.2.5-7.fc16

Package zlib-1.2.5-7.fc17:
* should fix your issue,
* was pushed to the Fedora 17 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing zlib-1.2.5-7.fc17'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2012-11432/zlib-1.2.5-7.fc17
then log in and leave karma (feedback).

zlib-1.2.5-7.fc16 has been pushed to the Fedora 16 stable repository.  If problems still persist, please make note of it in this bug report.

zlib-1.2.5-7.fc17 has been pushed to the Fedora 17 stable repository.  If problems still persist, please make note of it in this bug report.

Hi,

I am confused by this patch.  Why is it desirable to compile libz.a with -fPIC?
It is a static library, and those are typically compiled without -fPIC.  For
shared library linkage, libz.so is supplied.

Thanks,
Andy

See the original report.  On x86_64 static archives are required to be compiled with -fPIC as well.

Can you please point me to the relevant manual that explains it?  I have never
before heard of a requirement that static libraries need to be compiled with
-fPIC.  I thought the whole point of -fPIC was to allow the dynamic relocation
needed for shared libraries.  With static libraries, symbols are resolved at
link time, so -fPIC should not be needed.  It would be helpful for me to learn
if I am wrong about this.

Note: the original bug report supplied an error message, but it did not include
any context showing what generated the error.  So it is impossible to judge
what went wrong.

Thanks,
Andrew

Hi,

Can you please re-open this bug and revert the patch?  From the gcc manual:

http://gcc.gnu.org/onlinedocs/gcc-4.7.1/gcc/Code-Gen-Options.html#Code-Gen-Options

-fpic
    Generate position-independent code (PIC) suitable for use in a shared library, if supported for the target machine. Such code accesses all constant addresses through a global offset table (GOT). The dynamic loader resolves the GOT entries when the program starts (the dynamic loader is not part of GCC; it is part of the operating system). If the GOT size for the linked executable exceeds a machine-specific maximum size, you get an error message from the linker indicating that -fpic does not work; in that case, recompile with -fPIC instead. (These maximums are 8k on the SPARC and 32k on the m68k and RS/6000. The 386 has no such limit.)

    Position-independent code requires special support, and therefore works only on certain machines. For the 386, GCC supports PIC for System V but not for the Sun 386i. Code generated for the IBM RS/6000 is always position-independent.

    When this flag is set, the macros __pic__ and __PIC__ are defined to 1.
-fPIC
    If supported for the target machine, emit position-independent code, suitable for dynamic linking and avoiding any limit on the size of the global offset table. This option makes a difference on the m68k, PowerPC and SPARC. 


As it clearly says, these options are for making shared libraries, not static libraries.

Do I need to open a new bug to get this fixed?

Thanks,
Andy

Hi Andrew,

it looks like you are right, -fPIC option is not desirable for static libraries or executables. However, some packages tries to build shared libraries using statically built archives and then they can require -fPIC on static libraries. In this case, it is OK to build static library with -fPIC, but only on x86_64. On other architectures it's not needed and can cause performance impact at execution time. For more information see [1].

So.. for Fedora 16 and 17 I would keep it as it is now, I don't think this is worth an update.

And for rawhide and Fedora 18 I am thinking about enabling -fPIC for static library for x86_64 arch only, for compatibility reasons.. What do you think about this solution?

Thanks,

peter


[1] http://www.gentoo.org/proj/en/base/amd64/howtos/index.xml?part=1&chap=3

Hi,

I'm not sure I fully understand.  The only reason I can see for compiling a
static library with -fpic (or -fPIC) is if a developer wants to build his own
shared library that incorporates the libz.a contents.  However, I don't think
that is a good solution.  In such a case, the new shared library should simply
link in libz.so instead of trying to duplicate the libz code inside the new shared
library.

I may be missing something, but I think the standard approach is NOT to use
-fpic for a static library.  I don't see why libz.a should be different than
all the other static libraries on the system.  What am I missing?

Thanks,
Andrew

Well, as I said, you are right. The standard approach is not to use -fPIC for static library. But as you can see, (like this bug report), there are packages that fail to build if libz.a is compiled without -fPIC on x86_64. I understand that problem is in that package and not in libz.a, but this can happen not only to developers, but also to regular users who just need to compile some downloaded software. Also, it looks like there is no drawback for enabling -fPIC on static libraries only on x86_64 arch, so why wouldn't we help them?

peter

Hi Peter,

I'm not trying to be a hardass, but this is just wrong.  Would you compile
glibc with -fPIC if somebody requested it in a bug report without offering
any explanation of why?  This bug report does not even identify the code
that won't build.  The bug is in the other project, not in libz.a.  The bug
should be fixed in the proper place.  Static libraries should not be
compiled with -fPIC.

Those are my 2 cents.  I am baffled by the decision to compile a static library
with -fPIC.  It's just totally random.  Where's the list of packages that
require this?

Regards,
Andy

Andrew,

OK then. I was thinking about this and I'll revert this change in Fedora 18 and rawhide, so libz.a will be compiled without -fPIC.

peter

Thank you.

zlib-1.2.7-8.fc18 has been submitted as an update for Fedora 18.
https://admin.fedoraproject.org/updates/zlib-1.2.7-8.fc18

rawhide build:
zlib-1.2.7-8.fc19
http://koji.fedoraproject.org/koji/buildinfo?buildID=351163

zlib-1.2.7-8.fc18 has been pushed to the Fedora 18 stable repository.  If problems still persist, please make note of it in this bug report.