| |
| curl_off_t explained |
| ==================== |
| |
| curl_off_t is a data type provided by the external libcurl include headers. It |
| is the type meant to be used for the curl_easy_setopt() options that end with |
| LARGE. The type is 64bit large on most modern platforms. |
| |
| Transition from < 7.19.0 to >= 7.19.0 |
| ------------------------------------- |
| |
| Applications that used libcurl before 7.19.0 that are rebuilt with a libcurl |
| that is 7.19.0 or later may or may not have to worry about anything of |
| this. We have made a significant effort to make the transition really seamless |
| and transparent. |
| |
| You have have to take notice if you are in one of the following situations: |
| |
| o Your app is using or will after the transition use a libcurl that is built |
| with LFS (large file support) disabled even though your system otherwise |
| supports it. |
| |
| o Your app is using or will after the transition use a libcurl that doesn't |
| support LFS at all, but your system and compiler support 64bit data types. |
| |
| In both these cases, the curl_off_t type will now (after the transition) be |
| 64bit where it previously was 32bit. This will cause a binary incompatibility |
| that you MAY need to deal with. |
| |
| Benefits |
| -------- |
| |
| This new way has several benefits: |
| |
| o Platforms without LFS support can still use libcurl to do >32 bit file |
| transfers and range operations etc as long as they have >32 bit data-types |
| supported. |
| |
| o Applications will no longer easily build with the curl_off_t size |
| mismatched, which has been a very frequent (and annoying) problem with |
| libcurl <= 7.18.2 |
| |
| Historically |
| ------------ |
| |
| Previously, before 7.19.0, the curl_off_t type would be rather strongly |
| connected to the size of the system off_t type, where currently curl_off_t is |
| independent of that. |
| |
| The strong connection to off_t made it troublesome for application authors |
| since when they did mistakes, they could get curl_off_t type of different |
| sizes in the app vs libcurl, and that caused strange effects that were hard to |
| track and detect by users of libcurl. |
| |
| SONAME |
| ------ |
| |
| We opted to not bump the soname for the library unconditionally, simply |
| because soname bumping is causing a lot of grief and moaning all over the |
| community so we try to keep that at minimum. Also, our selected design path |
| should be 100% backwards compatible for the vast majority of all libcurl |
| users. |
| |
| Enforce SONAME bump |
| ------------------- |
| |
| If configure doesn't detect your case where a bump is necessary, re-run it |
| with the --enable-soname-bump command line option! |