Bug #1028

cpdup: not 64-bit clean

Added by msylvan about 6 years ago. Updated over 4 years ago.

Status:ClosedStart date:
Priority:NormalDue date:
Assignee:dillon% Done:

0%

Category:-
Target version:-

Description

cpdup cannot be built on 64-bit Linux (probably not on 64-bit DragonFly either,
once that becomes available).

Build log attached (using Fedora 9, GCC 4.3. Same problem occurs with GCC 4.2
and, as far as I remember, 4.1)

cpdup-buildlog.txt Magnifier (2.34 KB) msylvan, 06/05/2008 02:17 PM

cpdup-1.11-explicit_sizes.patch Magnifier (2.99 KB) msylvan, 06/11/2008 08:17 PM

cpdup-1.11-unused.patch Magnifier (3.75 KB) msylvan, 06/11/2008 08:20 PM

History

#1 Updated by dillon about 6 years ago

:New submission from Michel Salim <>:
:
:cpdup cannot be built on 64-bit Linux (probably not on 64-bit DragonFly eit=
:her,
:once that becomes available).
:
:Build log attached (using Fedora 9, GCC 4.3. Same problem occurs with GCC 4=
:.2
:and, as far as I remember, 4.1)

The only actual error is occuring inside a system include file, which
I have no control over.

The 64<->32 bit warnings just require casts. cpdup is installing a
32 bit protocol identifier as a pointer in the hclink code, and
converting it back on callbacks. It should work as-is but it does
need a clean-up to get rid of the 64 bit warnings. If someone wants
to do that and submit a patch that would be great.

-Matt
Matthew Dillon
<>

#2 Updated by msylvan about 6 years ago

Here is a patch implementing the explicit casts. I've used size_t rather than
int for the integral conversions of pointers.

#3 Updated by msylvan about 6 years ago

The 64-bit build errors are due to a namespace clash (or rather C's lack of
one): GLIBC's stat.h internally uses bits/stat.h, which on machines with 64-bit
wordsizes uses __unused for its own purpose. I've attached a patch that renames
every use of __unused in cpdup to __cpdup_unused; it works fine on Linux (the
build instructions will have to be modified accordingly)

#4 Updated by msylvan about 6 years ago

One last thing: could a COPYING or LICENSE file be packaged with the next
release of cpdup? It tends to be expected on Linux packages.

Thanks,

--
Michel

#5 Updated by joerg about 6 years ago

%zd or %zu?

(u)intmax_t + %jd/%ju is better here.

Joerg

#6 Updated by msylvan about 6 years ago

On 32-bit systems we pay a penalty for using intmax_t, as the pointer size will
only be 32-bit. size_t is always the same size as a pointer, as both are big
enough to range over all of addressable memory on a system

#7 Updated by dillon about 6 years ago

One can always use intptr_t. size_t is not a good abstraction for a
pointer-sized int.

-Matt
Matthew Dillon
<>

#8 Updated by msylvan about 6 years ago

Aha! Of course.. I was not familiar with it. Everything else is OK with both
patches, though?

#9 Updated by dillon about 6 years ago

:
:
:Michel Salim <> added the comment:
:
:Aha! Of course.. I was not familiar with it. Everything else is OK with both
:patches, though?

The __cpdup_unused is ok. Not fun, but I can't think of another solution
at the moment.

Lets not use size_t for the casts. Does linux have an intptr_t ? Can
we use that?

-Matt
Matthew Dillon
<>

#10 Updated by msylvan about 6 years ago

Linux does, it just did not occur to me at that time.

#11 Updated by erik-wikstrom about 6 years ago

intptr_t (and uintptr_t) is C99 so I would suspect that most modern
systems have them.

#12 Updated by msylvan almost 6 years ago

Just checking -- has the patch (modified to use intptr_t) been committed? I can
re-submit a corrected patch if necessary. Would like to drop the patch we use in
Fedora when the next version of cpdup comes out.

#13 Updated by swildner over 5 years ago

I've committed the casts but I'm rather reluctant about the __unused part.

#14 Updated by alexh over 4 years ago

is cpdup "64bit clean" now?

#15 Updated by sjg over 4 years ago

No update for some months, assume swildner's commit resolved this. Please
re-open if that is not the case.

Also available in: Atom PDF