[gentoo-amd64] Re: Re: gcc 4.1 + CFLAGS

[Duncan]

Samir Mishra <sqmishra@×××.ae> posted 448B34EC.9030009@×××.ae, excerpted
below, on  Sun, 11 Jun 2006 01:09:00 +0400:

> Duncan wrote:
>> A couple questions:
>>
>> -mcmodel=medium:  Here's the gcc 4.1.1 manpage entry:
>>
>> -mcmodel=medium
>>   [] Programs can be statically or dynamically linked, but
>>   building of shared libraries are not supported with the medium model.
>>
>> What about that last part -- shared libraries not supported?
>>
>>
> palladium ~ # file /bin/bash
> /bin/bash: ELF 64-bit LSB executable, AMD x86-64, version 1 (SYSV), for
> GNU/Linux 2.6.11, dynamically linked (uses shared libs), stripped
> palladium ~ # file /lib/libc-2.4.so
> /lib/libc-2.4.so: ELF 64-bit LSB shared object, AMD x86-64, version 1
> (SYSV), stripped

> I assume this is how to  check if a n executable or library is shared[.]
> I think I read somewhere that the above statement regarding lack of
> support for building shared libraries is not accurate[.] Memory usage
> seems reasonable for all of the applications, but given how much I know,
> quite possible I got it wrong.

Yes, that does check if it's shared, but unless there's something very
broken with your setup (I've seen it happen when an installation script
broke), shared libraries will always be *.so* (so is short for shared
object, and a *.so* file is comparable to the dll, dynamic link library,
so common on MSWormOS). Static libraries, OTOH, have the .a extension and
are collected and archived using shar (originally referring to
shell-archive, just like tar originally referred to tape-archive).

Static libraries must be compiled directly into the executable application
itself at compile time -- dynamic or shared libraries are loaded into the
application by ld at runtime.  Because static libraries are compiled into
the applications themselves, the resulting applications are much larger
(sometimes by several times), and consume much more memory, as there's a
copy of each library (or at least the parts of it used by the application)
for every application, all in memory at the same time.  Thus, the most
common parts of libc, for instance, will be duplicated in every single
app, both on disk and when they are loaded in memory!

Since you haven't noticed an extreme increase in memory usage, and the
*.so files seem to be there and usable, it's quite obvious that in fact
the gcc manpage IS inaccurate, in that case.  It obviously works for you
or by now you'd have a VERY VERY broken system and NOTHING would be
working.

So anyway, I learned that it at least isn't as bad as the gcc manpage
would lead one to believe. =8^)

That said, it /could/ be that gcc automatically disables that option for
shared objects, if it's such that it can do so.  I know it does so for
example with -freorder-blocks-and-partition, both because the manpage says
so, and because it spits out a warning when it does so that can be
problematic during the pre-compilation configure phase.  (It's for that
reason that I use that flag in CFLAGS but not in CXXFLAGS, because the use
of exceptions in C++ automatically disables it anyway, and the warning was
causing emerge failures.)  However, I'm not sure where the memory model
comes into use.  If it's only when linking the object files, gcc could
likely detect that it's creating a shared object and act accordingly.  If
it's while actually compiling the object files from source, then it
wouldn't necessarily know whether they were going to be shared objects or
applications at that point.

Thus, I'm not sure whether gcc is simply disabling that flag with shared
objects or whether it actually uses it but without the harm the use flag
implies will result.

Regardless, I remain of the opinion that for most apps, it's unnecessary
and will at minimum result in a larger binary than would otherwise be the
case, with no benefit, so it's all-negative, even if it doesn't actually
break anything.  Again, it's possible I'm wrong about that, but if I am,
it goes against all I've ever read on the subject.

I think the bit in your other reply about that comment of being sure you
research your CFLAGS before you use them coming back to bite you is a good
summation.  The discussion has been beneficial to both of us, however, as
my questioning is forcing a bit more research on your part, while I
learned that the results aren't quite as dire as the manpage implies they
are.  =8^)

>> -ftracer: Of interest here are a couple other manpage entries:
>>
>>
> I thought -ftracer, like -fweb, automatically did the profiling and the
> optimization. I was under the impression that -ftracer not recommended
> since it increases compile times (which I wasn't worried about) but
> produces "better" executables. If the profiling has to be done manually,
> prior to optimization, I definitely need to take this one out for my
> CFLAGS.

I'd still like to get a definitive answer from one of the devs that uses
it.  Presumably they won't be caught in the same trap of telling others to
know their CFLAGS, but not knowing their own, that this seems to have
caught you in.  =8^)  Maybe the manpage is incorrect here as well? <shrug>

> BTW I've heard bad things about using -fbranch-probabilities and -fweb.
> In fact, I tried -fweb with -ftracer and I began experiencing numerous
> compilation failures. Everything went back to OK when I took it out.

Very interesting.  I'd not been aware of such.

I wonder... maybe they are the automatic-profiling and manual-profiling
parallels of the same thing?  If so, it would explain both the problems
you experienced trying to use both together and the reason one is implied
to be manual while the other is evidently automatic.

I'm afraid I'm raising more questions than I have answers! =8^(

> In conclusion, I THOUGHT I had good reason, but I guess I need to do a
> bit more research.

You know... I've come to realize that ironically, I often value the
opinions of and discussions/debates/arguments with those I disagree with
most, particularly where they honestly challenge me and I them, more
highly than those I tend to agree with. The reason is precisely your
conclusion above -- those discussions/debates/arguments tend to spotlight
the weakest points in my reasoning that I'd be very unlikely to find it on
my own, thus stimulating an acknowledgement that I can't defend that
particular point at that particular time and further research, which
ultimately leads to either understanding my own position better, or a
retraction from it.  Had I not been forced by the other person to face
that weakness, I'd have never found it and therefore never had a chance to
adjust to it or for it.  For that reason, I consider that person to have
done me a favor for helping me find what I would have otherwise been
unaware of, and hold an even greater respect for them than I do for those
I always agreed with.

So, it seems we are both learning here.  I certainly had my misconception
that the medium memory model would result in a broken system if used in
CFLAGS while attempting to compile shared objects disproved, and you've
learned your position wasn't as secure as you believed it to be, either. 
I think that means we've both benefited!  =8^)

The great thing about doing this on the public mailing list, is that
others benefit as well.  I know I'm always learning things from the
discussions of others!



-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

-- 
gentoo-amd64@g.o mailing list