WelcomeWelcome | FAQFAQ | DownloadsDownloads | WikiWiki

Author Topic: compiler flags  (Read 1708 times)

Offline jls

  • Hero Member
  • *****
  • Posts: 2135
compiler flags
« on: July 09, 2012, 08:43:22 AM »
In the enlightenment wiki are suggested this compiler flags:
Code: [Select]
        CFLAGS=-fvisibility=hidden -O2
        LDFLAGS=-fvisibility=hidden
while in the tc wiki is written:
Code: [Select]
export CFLAGS="-march=i486 -mtune=i686 -Os -pipe"
export LDFLAGS="-Wl,-O1"
what should I do?
dCore user

Online curaga

  • Administrator
  • Hero Member
  • *****
  • Posts: 11035
Re: compiler flags
« Reply #1 on: July 09, 2012, 12:13:02 PM »
Use both, they don't conflict (other than O2 and Os, pick one).

ie CFLAGS="-march=i486 -mtune=i686 -Os -pipe -fvisibility=hidden"
The only barriers that can stop you are the ones you create yourself.

Offline Rich

  • Administrator
  • Hero Member
  • *****
  • Posts: 11540
Re: compiler flags
« Reply #2 on: July 09, 2012, 12:32:12 PM »
Hi jls_legalize
Quote
export CFLAGS="-march=i486 -mtune=i686 -Os -pipe"
export LDFLAGS="-Wl,-O1"
The TC Wiki lists those as suggest flags, and goes on to mention some flags to try for special situations, and
finally some not-allowed flags. The way I read it, you should try to use the suggested flags whenever possible, but
you do have the leeway to use/add other flags if you need them and they are not in the not-allowed list.
According to the fvisibility Wiki (http://gcc.gnu.org/wiki/Visibility) it should produce "better" code, but there is a
warning that in C++ exceptions may not work correctly if the source code doesn't have visibility correctly defined
for all data. A small excerpt from the Wiki:
Quote
The upshot of this is that if you forget your preprocessor defines in just one object file, or if at any time a throwable type is not declared explicitly public, the -fvisibility=hidden will cause it to be marked hidden in that object file, which overrides all the other definitions with default visibility and causes the typeinfo to vanish in the outputted binary (which then causes any throws of that type to cause terminate() to be called in the catching binary). Your binaries will link perfectly and appear to work correctly, even though they don't.
If I understand it correctly, it says that an exception that could normally have been dealt with by the program will
cause it to terminate instead, you just won't know about the problem until or if the exception is actually encountered
and thrown.