You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@apr.apache.org by Friedrich Dominicus <fr...@q-software-solutions.de> on 2004/11/24 12:19:20 UTC
portability
This may sound a bit ridicolous, however I wonder how serious you are
about the portability of the code used for libapr. Is it wanted that
compiler/llibrary internals of specific compilers are used? Or is that
considered a bug?
Regards
Friedrich
Re: portability
Posted by Friedrich Dominicus <fr...@q-software-solutions.de>.
sorry, it should have gone to the list. I probably just have hit
reply...
Regards
Friedrich
Re: portability
Posted by Friedrich Dominicus <fr...@q-software-solutions.de>.
"William A. Rowe, Jr." <wr...@rowe-clan.net> writes:
> At 01:07 PM 11/24/2004, Friedrich Dominicus wrote:
>>"William A. Rowe, Jr." <wr...@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.
>>lcc-win32
>>__LCC__
>>
>>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.
That's interesting, the .dsw file I had uses poll.c from the unix
subdirectory at least it was part of the project...
>
>>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.
That is what I'm going to do again and I have to check how the build
process is supposed to work I assume I've modfied files I should not
have touched ....
Regards
Friedrich
Re: portability
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
At 01:07 PM 11/24/2004, Friedrich Dominicus wrote:
>"William A. Rowe, Jr." <wr...@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.
>lcc-win32
>__LCC__
>
>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)
>#else
>#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
>required.
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.
Bill
Re: portability
Posted by Friedrich Dominicus <fr...@q-software-solutions.de>.
"William A. Rowe, Jr." <wr...@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.
lcc-win32
__LCC__
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.
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
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)
#else
#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
required.
Regards
Friedrich
Re: portability
Posted by Friedrich Dominicus <fr...@q-software-solutions.de>.
Garrett Rooney <ro...@electricjellyfish.net> writes:
> Friedrich Dominicus wrote:
>> This may sound a bit ridicolous, however I wonder how serious you are
>> about the portability of the code used for libapr. Is it wanted that
>> compiler/llibrary internals of specific compilers are used? Or is that
>> considered a bug?
>
> It needs to be portable ;-)
>
> Seriously, if you have some way to make something a bazillion times
> faster by using a gcc extension then I suppose it might be considered,
> but you'd also have to provide a non-gcc version of the code for cases
> where that wasn't possible. People compile APR with all sorts of
> compilters.
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);
}
#else
*/
if (((*new)->td = CreateThread(NULL,
attr && attr->stacksize > 0 ? attr->stacksize : 0,
(unsigned int (APR_THREAD_FUNC *)(void *))dummy_worker,
(*new), 0, &temp)) == 0) {
return apr_get_os_error();
}
// #endif
The latter works on Windows XP and probably others as well whereas the
first one uses a compiler specific internal symbol
Regards
Friedrich
Re: portability
Posted by Garrett Rooney <ro...@electricjellyfish.net>.
Friedrich Dominicus wrote:
> This may sound a bit ridicolous, however I wonder how serious you are
> about the portability of the code used for libapr. Is it wanted that
> compiler/llibrary internals of specific compilers are used? Or is that
> considered a bug?
It needs to be portable ;-)
Seriously, if you have some way to make something a bazillion times
faster by using a gcc extension then I suppose it might be considered,
but you'd also have to provide a non-gcc version of the code for cases
where that wasn't possible. People compile APR with all sorts of
compilters.
-garrett