Operating System - HP-UX
1753521 Members
4894 Online
108795 Solutions
New Discussion юеВ

Re: What are the implications of building gcc as shared vs static?

 
SOLVED
Go to solution
Philip Reyniers
Advisor

What are the implications of building gcc as shared vs static?

To All:

Just a question for clarification / discussion. What are the implications of building gcc using --enable-shared vs --disable-shared?

5 REPLIES 5
A. Clay Stephenson
Acclaimed Contributor

Re: What are the implications of building gcc as shared vs static?

Well, both the HPUX.Install notes and the configure file indicate that the gcc binaries break if you set enable-shared to "yes". This does not mean that you cannot use shared libraries with the gcc produced code but rather that the gcc and binutils themselves do not use shared libraries. This is a case where I would trust those who have gone through this before you. I don't use gcc on anything but Linux.
If it ain't broke, I can fix that.
Steve Ellcey
Valued Contributor

Re: What are the implications of building gcc as shared vs static?

It depends on which hpux platform you are on (PA/IPF 10.20/11.*...) and which version of GCC you are building. In general if you build with --disable-shared you will not build shared versions of libgcc, libstdc++, or any other of the GCC runtime libraries. --enable-shared will cause the shared versions of those libraries to be built. The GCC built with --disable-shared will still try to link with shared libraries if it can find them, thus it may still link with the shared libc. As far as I know --enable-shared will work on all the 11.* HPUX platforms for GCC 3.3.* and GCC 3.4.* releases.
Philip Reyniers
Advisor

Re: What are the implications of building gcc as shared vs static?

I am using HP-UX 11i and am trying to determine the ramification(s) of building gcc 3.4.3 with shared enabled. My thoughts are that if gcc is built with shared enabled then items such as Perl would be linked against the gcc shared libraries. Thus creating a situation where those gcc shared libraries must remain on the server. This might not be what one is looking for when creating software packages. So my thought is that gcc 3.4.3 should be built with shared libraries disabled to prevent add-on software builds from being linked against the core gcc libraries.
Steve Ellcey
Valued Contributor
Solution

Re: What are the implications of building gcc as shared vs static?

I think your analysis is correct. At the very least you would be requiring people using your package to have libgcc.sl on their system to run your package. If you had C++ code they would also need libstdc++-v3.sl. If all the code was C, you could link your packages with -static-libgcc and avoid the libgcc.sl dependency even when using a GCC built with --enable-shared. But C++ code would still require libstdc++-v3 unless you went all the way and linked with -static to avoid using any (GCC or system) shared libraries when building.
Philip Reyniers
Advisor

Re: What are the implications of building gcc as shared vs static?

Yes, that is my thought also. One could be setting themself up for maintainability and portability issues. Which is not a good thing. Thanks! I will leave the thread open for now. If you think of any other issues then please post.

:)