Re: [boost] Problem with libs/system/src/error_code.cpp

From: Vladimir Prus (ghost_at_[hidden])
Date: 2006-12-19 04:08:45

Oliver.Kowalke_at_[hidden] wrote:

>  
>> > would result in a problem with ::accept(). If the listen socket on
>> > which ::accept() is called is non-blocking, then the
>> returned socket
>> > from ::accept() is blocking. This behaviour is different on HP/UX
>> > 11.11 were the new socket is also non-blocking.
> 
>> I would have expected the cross-compiler to have some define
>> that says you're compiling for HP/UX so that you change your
>> code using preprocessor.
> 
> That's what autoconf does for you. The only thing you have to do is to
> prepare some macros which check if the requested feature is available
> and then produces a preprocessor define (like HAVE_MSG_NOSIGNAL).
> The benefit is that it is more genreric than checking in the code for
> the OS/OS version/OS release

It looks like this turns into general "autoconf is good" discussion, which
is not how it started.

Here's what you've said before:

        > No, that doesn't work; you need to know the OS version for 
        > deployment to know what's available at runtime.

        Autoconfig could help in this place - could this be integrated in the
        boost build process?

That statement seems to say that autoconf has additional support for
the case where the target system is not the same as the build system,
and such support can help with the filesystem library.

Can you specifically say which support is that?

> Like:
> 
> #if defined (LINUX || Solaris_10)
> strerror_r
> #elif defined (Solaris_28 || HP/UX_11)
> strerror
> #else
> 
> 
> #ifdef HAS_STRERROR_R
> strerror_r
> #else
> strerror
> #endif

While autoconf's compile tests are more general than using just preprocessor
symbols, it's not yet established that preprocessor symbols won't work
in this case.

>> If it's not possible, then you'd have to set your own define
>> manually, when building for HP/UX.
> 
> see above
> 
>>I don't think autoconf can
>> run a binary for target system to check run-time properties,
>> even if you have the target system around.
> 
> Autoconf does run m4 macros (some already provided - but you can also
> implement your own) before you start compiling your source code.

I did not claim otherwise. But running m4 macros is not the same as running
binaries -- you cannot run a binary for the target system unless you
have the target system at hand. And even if you have it at hand, I don't
think autoconf can run binaries for the target system.

- Volodya