apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <wr...@rowe-clan.net>
Subject Re: portability
Date Wed, 24 Nov 2004 18:35:05 GMT
At 01:07 PM 11/24/2004, Friedrich Dominicus wrote:
>"William A. Rowe, Jr." <wrowe@rowe-clan.net> writes:
>> At 08:24 AM 11/24/2004, Friedrich Dominicus wrote:
>>>How about this code then?
>>>/* #ifndef _WIN32_WCE
>>>    if (((*new)->td = (HANDLE)_beginthreadex(NULL,
>>>                        attr && attr->stacksize > 0 ? attr->stacksize
: 0,
>>>                        (unsigned int (APR_THREAD_FUNC *)(void *))dummy_worker,
>>>                        (*new), 0, &temp)) == 0) {
>>>        return APR_FROM_OS_ERROR(_doserrno);
>>>    }
>> If you let us know which compiler fails for you, we can
>> have a look at it.  Let us know the compiler's defined()
>> macro signature as well.
>However there are a bunch of other things I had to add/modify to 
>get libapr0.93 somehwat compiled. I now fail miserable with the 1.x
>version because of poll problem. 

What poll problem?  we use network_io/unix/select.c, not poll.c.

>Howerver it was still not an easy going to get libapr compiled on
>MSVC, so I either I've messed up my MSVC, Windows or libapr or the
>might be another problem

You might try a clean checkout.

>The point which we have trouble with are this declarations 
>#elif defined(APR_DECLARE_EXPORT)
>#define APR_DECLARE(type)            __declspec(dllexport) type __stdcall
>#define APR_DECLARE_NONSTD(type)     __declspec(dllexport) type
>#define APR_DECLARE_DATA             __declspec(dllexport)
>#define APR_DECLARE(type)            __declspec(dllimport) type __stdcall
>#define APR_DECLARE_NONSTD(type)     __declspec(dllimport) type
>#define APR_DECLARE_DATA             __declspec(dllimport)
>The declaration while building a DLL seem to be ok, but Mr Navia the
>author of lcc-win32 thinks that the APR_DECLARE in the else part is
>wrong. Maybe you can point us to the documentaton on where this is

There is no error.  You need to declare dllimport in order
to ensure these functions are mapped.  If Mr Navia is certain
that all relocation stubs (ESPECIALLY data relocations!!!) don't
need special handling under lcc, he should simply recognize and
ignore that __declspec construct.

If you are trying to build STATIC .lib - you must define the
macro APR_DECLARE_STATIC when building the library.  You can
also use it when compiling against the static library headers
in your own app to save the compiler lots of fixups.


View raw message