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

 
 

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

Submitted by:  Mathieu Bridon <bochecha>
Submitted on:  Sun 13 Jun 2010 08:34:10 AM UTC  
 
Category: NoneSeverity: 3 - Normal
Item Group: NoneStatus: Fixed
Privacy: PublicAssigned to: Kai Sterker <ksterker>
Open/Closed: Closed

Add a New Comment (Rich MarkupRich Markup):
   

You are not logged in

Please log in, so followups can be emailed to you.

 

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>
Project AdministratorIn charge of this item.
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>
Project AdministratorIn charge of this item.
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 File(s):
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

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

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.

     

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    Follow 5 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Tue 27 Jul 2010 09:27:52 PM UTCksterkerStatusPostponed=>Fixed
      Open/ClosedOpen=>Closed
    Sun 20 Jun 2010 09:37:30 AM UTCksterkerStatusNeed Info=>Postponed
    Sun 13 Jun 2010 10:30:45 AM UTCksterkerStatusNone=>Need Info
      Assigned toNone=>ksterker

    Back to the top


    Powered by Savane 3.1-cleanup