cURL / Mailing Lists / curl-library / Single Mail

curl-library

Re: design problem with CURL_SIZEOF_LONG in 7.19.0

From: Yang Tse <yangsita_at_gmail.com>
Date: Fri, 5 Sep 2008 21:17:15 +0200

2008/9/5 Tor Arntsen wrote:

> On Thu, Sep 4, 2008 at 19:00, Yang Tse wrote:
>> Now each configured and built libcurl.so has its own set of headers
>> which must be distributed and match the built library. It is true that
>> on nearly all platforms you can not use 32-bit libcurl headers for a
>> 64-bit built libcurl library, as well as the contrary.
>
> Ah, I didn't fully realize that during the discussions.. this could be
> a bit tricky for those platforms where you can build both 32- and
> 64-bit executables as you please, e.g. IRIX and AIX. Solaris too,
> although I haven't used the 64-bit feature there.

There are only a couple of things to keep in mind while planning how
each one or an organization wants things done and layed out on each
platform. It is true that the layout design decisions have to be done
before building the library, at least at this point, due to the fact
that 'curl-config', which is library dependant, will be installed in
the same subdirectory as the curl utility.

> On IRIX there are
> two different sets of runtime libraries (/usr/lib32 and /usr/lib64.
> And even /usr/lib for the old o32 format). The same for the IRIX
> freeware tree (/usr/freeware/lib{32,64}/). But there are only the
> common /usr/include and /usr/freeware/include directories for 32- and
> 64-bit executables.

Obviously libcurl built libraries, depending on the kind of build,
should be placed in:

/usr/lib32
/usr/lib64
/usr/lib

And the corresponding header files installed in:

/usr/include/x64/curl/*.h
/usr/include/n32/curl/*.h
/usr/include/o32/curl/*.h

For the freeware tree it would be:

/usr/freeware/lib32
/usr/freeware/lib64

And the corresponding header files installed in:

/usr/freeware/include/inc32
/usr/freeware/include/inc64

The two ideas behind these layouts are:

Configure each kind/target of library so that the binary library is
installed in its appropriate system lib subdirectory. "IRIX cc -n32 to
/usr/lib32", "IRIX cc -64 to /usr/lib64" and "IRIX cc -o32 to
/usr/lib". I assume that the compiler already knows which library
subdirectory must be searched later to link against each library.

For such a system with 3 possible library configurations, and for
anyone with more than a single configuration, the concept of default
include path for libcurl's header files should be abandoned. No set of
libcurl header files should be 'include-able' without explicit
specification of the desired one. Each configuration has its own
include path, and set of libraries, that must be specified by the
developer while building his application. No default include path for
libcurl's header files unless there is one single posibility on the
system.

For executables something very similar happens you can not have 32 and
64-bit curl executables with the same name in the same subdirectory.
This is obvious and the issue already existed way before the existance
of the configurable header files.

> So, how would one make 32- and 64-bit versions of libcurl for e.g.
> IRIX? Without breaking the standard install tree structure? (If I were
> to do this myself I think I would have to resort to a manual merge,
> with #ifdefs, for the headers.)

Untested but probably something based on the following would work:

./configure --libdir="/usr/lib" --includedir="/usr/include/o32"
--bindir="/usr/bin/o32"
make
make install
make clean
./configure --libdir="/usr/lib32" --includedir="/usr/include/n32"
--bindir="/usr/bin/n32"
make
make install
make clean
./configure --libdir="/usr/lib64" --includedir="/usr/include/x64"
--bindir="/usr/bin/x64"
make
make install
make clean
./configure --libdir="/usr/freeware/lib32"
--includedir="/usr/freeware/include/inc32"
--bindir="/usr/freeware/bin32"
make
make install
make clean
./configure --libdir="/usr/freeware/lib64"
--includedir="/usr/freeware/include/inc64"
--bindir="/usr/freeware/bin64"
make
make install
make clean

> Tru64 is 64-bits only afaik so that one is simple at least.

In any case all this world of possibilities has not been triggered
with the curlbuild.h file, these already existed. The only thing that
the new header files introduce is the means so that these
possibilities can be properly used.

-- 
-=[Yang]=-
Received on 2008-09-05