This is the mail archive of the libstdc++@gcc.gnu.org mailing list for the libstdc++ project.


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

Re: Porting Questions


"David A. Greene" <greened@eecs.umich.edu> writes:

| I'm still working on porting libstdc++-v3 to our compiler.
| I've run across a couple of problems that I'd like to get
| some opinions on:
| 
| - There are many places where gcc's __builtin_* functions
| are called.  Obviously, we don't have these.  Right now
| I've #ifdef'd the code to call __builtin_* when __GNUC__
| is defined and * otherwise.  I don't like this solution
| in the long run, so would an additional test for these
| functions and #define be appropriate?  For example, test
| for __builting_alloca and #define ALLOCA_FUNCTION to
| alloca or __builtin_alloca as appropriate.

Basically we build a config header file at configure time pretty much
like c++config.h. Then your create a file, call it your-stubs.cc
(#including you header config file) where you define the 
missing functions.  Then you link it to the library.
You don't need to play macro hackery games.  If your compiler happens
to implement the missing __builtin_xxx then the only thing you need is
to remove your-stubs.cc.

| - I have the same problem with NULL.  Our compiler doesn't
| like the assignment of (void *)(0) to non-void pointers.
| I could test for this as well and #define NULL_POINTER
| to the appropriate thing.  Is there a better way.

Just redefine it -- anyway, (void *)0 is not acceptable for C++.

[...]

| How does this build work under g++ (i.e. how does it get
| all the instantiations right when it can't see all the
| code?)

This depends on how friendly is the host linker. A thorny issue,
requiring generally non contorsious solutions.

-- Gaby


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