bugAdonthell - Bugs: bug #30123, Adonthell doesn't build on Fedora...

 
 

bug #30123: Adonthell doesn't build on Fedora 14 i686

Submitter:  Mathieu Bridon <bochecha>
Submitted:  Sun 13 Jun 2010 08:34:10 AM UTC
   
 
Category:  None Severity:  3 - Normal
Item Group:  None Status:  Fixed
Privacy:  Public Assigned to:  ksterker
Open/Closed:  Closed
* Mandatory Fields

Add a New Comment Rich Markup
   

Tue 27 Jul 2010 09:06:50 PM UTC, comment #4: 

I just closed the Fedora bug report, since an update to zlib was issued and Adonthell now builds properly.

Thanks for the help in diagnosing the issue. :)

Mathieu Bridon <bochecha>
Sun 20 Jun 2010 09:37:30 AM UTC, comment #3: 

Thanks for checking into that. At the time I looked into the Fedora Bug DB I couldn't really find anything similar, so I wasn't really sure.

As for the proposed workaround. I would only go with that as a last resort, if the issue will not be adressed by zlib. For one, ZLIB_INTERNAL does sound like something internal to zlib, probably used when compiling zlib itself. Hard to say what side effects it has when using zlib (without looking at all the header files).
Same goes for the _LARGEFILE64_SOURCE, which is defined by the underlying c library, probably for good reasons.

The biggest gripe, however is that with this new combination of flags, you essentially disable 64bit support of zlib on 32bit systems. I imagine that this could bite users of Adonthell if data files or savegames reside near the end of a large enough partition. Didn't do the math to figure out how large a partition has to be to actually require 64bit adressing, so not sure if this is a valid case for home users, but it's something to keep in mind.

Kai Sterker <ksterker>
Group administrator
Sun 20 Jun 2010 08:55:41 AM UTC, comment #2: 

Apparently you are right, it does seem like an issue in recent zlib. I've found reports of the same build issue for several sowftware, on different distros. Gentoo even has a patch (not yet accepted upstream) that « fixes » the issue.

However, it is still discussed upstream, and it is not clear if the issue is in Zlib proper or in the way projects link to it.

Food for thought, Hicham managed to build Adonthell on Fedora 14 by playing with CFLAGS:
-make %{?_smp_mflags}
+make %{?_smp_mflags} CFLAGS="%{optflags} -DZLIB_INTERNAL -U_LARGEFILE64_SOURCE -DDATA_DIR=\"%{_datadir}\" -Wno-deprecated " \
+                     CXXFLAGS="%{optflags} -DZLIB_INTERNAL -U_LARGEFILE64_SOURCE -DDATA_DIR=\\\"%{_datadir}\\\" -Wno-deprecated "

(that's a diff in the RPM spec file)

Do you think that makes sense?

I'll wait for upstream zlib before I update the Fedora package, but I just wanted to let you know in the meantime.

Mathieu Bridon <bochecha>
Sun 13 Jun 2010 10:30:45 AM UTC, comment #1: 

Wish I could tell you to upgrade to v0.4, but that won't be ready for a while ...

Regarding the problem, if you look into zlib.h (v1.2.5) at the line numbers the error spits out, you'll see:

#if defined(_LARGEFILE64_SOURCE) && _LFS64_LARGEFILE-0

where it defines one set of 64bit functions and then

#if !defined(ZLIB_INTERNAL) && _FILE_OFFSET_BITS-0 == 64 && _LFS64_LARGEFILE-0
#  ifdef _LARGEFILE64_SOURCE

where it defines another, conflicting set. For some reason, it runs into both blocks because of the way the defines are set up. Obviously, we have

_LARGEFILE64_SOURCE=true
_LFS64_LARGEFILE=true
_FILE_OFFSET_BITS=64
ZLIB_INTERNAL=false

From my understanding, _LARGEFILE64_SOURCE and consorts are defined by glibc (if a 32bit OS should support large files). That's why you are seeing the problem on i686 only.

Since all this is internal to glibc/libz, there isn't anything we can do about this. The main question is, does the same problem happen on any other package using zlib (I would assume so) or is it just Adonthell that is affected. In latter case, it might be caused due to some unfortunate mix of libraries that might affect the state of those flags. In that case, shuffling the includes around might help.

As I do not have a 32bit system with large file support around for testing, I would ask you to check first if other packages exhibit the same issue. Might as well be a bug in recent libz. If not, I'll try to think of something.

Kai Sterker <ksterker>
Group administrator
Sun 13 Jun 2010 08:34:10 AM UTC, original submission:  

During the Fedora development cycle, we try to rebuild all our packages to ensure that Fedora is a self-hosted platform and that our users are always free to build Fedora from source.

Adonthell failed to build from source on the future Fedora 14 on the i686 architecture.

See the downstream bug:
https://bugzilla.redhat.com/show_bug.cgi?id=599946

The build log is attached to the downstream bug:
https://bugzilla.redhat.com/attachment.cgi?id=420547

Note that Adonthell builds fine on x86_64:
http://linux.dell.com/files/fedora/FixBuildRequires/mock-results/x86_64/adonthell-0.3.5-0.8.fc12.src.rpm/result/build.log

Mathieu Bridon <bochecha>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by ksterker (Posted a comment)
  • -email is unavailable- added by bochecha (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

    Follow 5 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2010-07-27 ksterker StatusPostponed Fixed
        Open/ClosedOpen Closed
    2010-06-20 ksterker StatusNeed Info Postponed
    2010-06-13 ksterker StatusNone Need Info
        Assigned toNone ksterker

    Back to the top

    Powered by Savane 3.13-4448.
    Corresponding source code