Re: How do I add missing stdc functions to libstdc++-v3?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


On 2012-03-06, at 4:51 PM, Jonathan Wakely wrote:

> On 6 March 2012 20:53, Vaugha Brewchuk wrote:
>> Thank you for a super-fast response!
>> 
>> I was compiling abi_check.cc using make check.  The NeXT supplied libraries are very old and do not include all of the libstdc++ dependencies.  Specifically, strxfrm() and strdup() are not in the NeXT libraries and therefore my plan was to add them to libstdc++ so that the dependency is satisfied locally.
> 
> Those functions are required by C90 so it's not surprising that
> libstdc++ (even such an ancient version as 3.2.3) assumes they are
> available.  I think the usual way to provide them would be in
> libiberty, not in libstdc++
> See http://gcc.gnu.org/onlinedocs/libiberty/

Thank you for the suggestion - I will review the documentation for libiberty and see if I can build it with some additional functions.

> 
>>  On the other hand access() and write() are in the NeXT libraries, but are defined in header libc.h, that libstdc++ does not recognize out of the box...
> 
> I doubt those functions are defined in a header, note the error you're
> getting is an undefined reference - meaning the library containing the
> functions hasn't been found.  Not finding a header isn't the problem.
> Which library defines them?

It looks like the actual objects for access() and write() reside in /usr/shlib/libsys_s.B.shlib, which is a shared library that is automatically loaded, if needed, by the standard NeXT static library /lib/libsys_s.a.  To confirm I just created a short test program in C that uses write() and compiled it with my C only port of gcc-3.2.3 using the following command:

gcc -o test -Wall test.c

It compiles and links successfully, creating a test executable that includes the write() object.  I wonder if this has something to do with the way that NEXTSTEP 3.3 libraries are set-up and the way collect2 works.  What I don't understand is that it works fine with C executables, but not with C++ executables.

> 
> Is there a reason you're porting such an ancient GCC rather than a
> newer version which might work better on NeXT, or might be fixable if
> you report bugs in its support for NeXT?

Unfortunately gcc-3.2.3 is the most modern GCC that supports the NeXT out of the box, and even then only with the obsolete flag.  Any newer versions would require significant effort to implement NeXT support, since I understand that the platform configuration files have been completely changed.  I would love to port a more modern compiler, but it is substantially beyond my abilities.  Just for reference, NEXTSTEP 3.3 originally shipped with gcc-2.5.8, so 3.2.3 is a significant upgrade already :-)

Thank you again.




[Linux C Programming]     [Linux Kernel]     [eCos]     [Fedora Development]     [Fedora Announce]     [Autoconf]     [The DWARVES Debugging Tools]     [Yosemite Campsites]     [Yosemite News]     [Linux GCC]

Add to Google