This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug other/28377] unresolved symbols in libstdc++, shared lib link strategy of libgcc.a



------- Comment #5 from marek dot rouchal at infineon dot com  2006-07-14 14:01 -------
Ok, the compile is done. In gcc/Makefile.in, I changed
    -DLOCAL_INCLUDE_DIR=\"$(local_includedir)\" \
to
    -ULOCAL_INCLUDE_DIR \
so that /usr/local/include is NOT searched by default by the preprocessor.
This way I do not source the evil assert.h in that path, and everything now
works smoothly - the __eprintf is gone from libstdc++.so, and I do not see this
popping up in any other compiles - as I do not search /usr/local/include any
more. So all is fine now.

Suggestions:

- make the assert.h/__eprintf trouble a FAQ:
  "Whenever you see an unresolved symbol __eprintf, this most likely means that
you have an old and buggy assert.h in some of your include directories. Note
that cpp has some built-in search paths that you may need to consider as well,
like /usr/local/include"

- remove /usr/local/include from the standard include file search path; only
the _real_ standard locations for the platform (/usr/include) should be
considered, anything else should be up to the user - and it is easy
(-I/usr/local/include)

Thanks for your quick help,

Marek


-- 

marek dot rouchal at infineon dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |INVALID


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28377


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]