Opened 11 years ago

Closed 11 years ago

#3769 closed Bug (invalid)

Can't resolve symbol 'gzopen64'

Reported by: KyleK Owned by: charles
Priority: Normal Milestone: None Set
Component: libtransmission Version: 2.12
Severity: Normal Keywords:


Someone at the DNS-323 forum stumbled over this:

I'm surprised this is a runtimer error. I noticed when compiling Transmission 2.12 that there were warnings about implicit declaration of 'gzopen64', but it didn't result in a linker error, so I figured it was just missing the proper include.

But, alas, it seems to cause problems, at least on the NAS device.

Any idea what might be the reason for this?

Change History (2)

comment:1 Changed 11 years ago by charles

This smells like a build issue, but I'm not positive. The symbol is probably coming from the call to gzopen() in libtransmission/rpcimpl.c, which is apparently getting translated to gzopen64() somewhere during compilation. I haven't seen t his reported for Transmission before but some cursory googling of gzopen64() indicates a couple of things to try:

  1. Upgrade zlib and see if that fixes it
  1. Try find what system header is #defining gzopen() as gzopen64() so that we can figure out why it's being converted

(As an aside, the user should find a different blocklist than the one hosted at It disappear as soon as I can remove it without flat-out breaking the feature for Linux users who can't upgrade to >= 2.12 until the Spring Linux release cycle rolls around. You probably want to point the forum members to another blocklist.)

comment:2 Changed 11 years ago by charles

  • Resolution set to invalid
  • Status changed from new to closed

I've uploaded a new Transmission package. This is still v2.12, but I fixed the problem FunFiler? was talking about (gzopen64 not available).

The problem was that I had installed a newer version of zlib, which was a bad idea smile

Note: See TracTickets for help on using tickets.