[Bug 20042] Wine does not build on amd64 when linking to 32-bit libmpg123

[wine-bugs at winehq.org]

http://bugs.winehq.org/show_bug.cgi?id=20042





--- Comment #36 from Thomas Orgis <thomas-forum at orgis.org>  2010-02-11 09:06:50 ---
I am not sure what to respond to this. I do have the suspicion that mpg123 is
not alone with the issue of having to prevent bad combinations of applications
and libraries using 32 bit or 64 bit off_t. Be reminded that the header would
look identical for i386 and x86-64 would 64 bit off_t be the default on a 32bit
build.
This whole mess mainly arises because a default build of libmpg123 enables 64
bit offsets via configure but when you simply build a program using libmpg123
and do not specify special compiler flags, your program will use a 32 bit
off_t.

Without the check I built into the header, this would cause funny unspecified
behaviour when using the API that expects 64 bit offsets. I assume that there
are libraries that let that just happen... and this is mostly not an issue
because distributions carefully build everything with largefile support(?). In
hindsight, I perhaps should have not added that check. Most people would not
notice and be happy, some people would have strange issues...

Now, for the option of implementing both 32 bit and 64 bit API, just like libc.
Is it really a good idea to recreate that hack in each library relying on the
"magic" of off_t? It seems like the other real option is to use yet another
custom typedef for offsets and internally convert between that and the actual
off_t the library uses. That includes handling EOVERFLOW and friends. It is not
fun.
I'd rather avoid such cruft before doing it incorrectly. And also, what will a
user of the library do? Especially if the user uses other libraries that yet
again have other custom file offset types... there will be blind casts without
checking.

I do not feel comfortable having to devise header machinery that corretly maps
functions to wrappers that handle 32 bit / 64 bit conversion... I will need to
add architecture-dependent macros... see that there only is 64 bit off_t on an
x86_64 system; detect i386 systems that need _32 and _64 functions... and then
prevent this all do do something on *BSD, where off_t is just 64 bits, period.
Such a header would not be platform-independent. It would be specific to the
set of platforms that are covered in the preprocessor machinery.

But I want to have my code portable, using off_t and detecting at
configure-time if large file support shall be enabled is portable. Every line
of complication to the header makes it more likely that some configuration will
be broken without need.

I see the problem really with the distributions: When they do multilib, they
need to store both verisons of the header file, each matching its library. For
a distribution it is trivial to install a wrapper in /usr/include that includes
a 32 bit or a 64 bit header depending on x86 / x86-64 (SPARC / SPARC64, PPC /
PPC64) build being selected.
That can be automated in the distribution's build system. They know what
architectures / ABIs they support. They know what default compiler they
support.

Until such proper solution is in place, the workaround I offered should do the
trick. When wine is configured with largefile support for 32 bit code, it just
needs to add -DMPG123_FORCE_LARGEFILE=_64 to its CPPFLAGS. That won't work for
mpg123 versions < 1.10.1, but we cannot change the past, anyway.

If this is really not acceptable, I am open to further discussion...

-- 
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
Do not reply to this email, post in Bugzilla using the
above URL to reply.
------- You are receiving this mail because: -------
You are watching all bug changes.