ld doesn't support -lm

[austin987]

Needed by wine...

[mmlr]

There is no libm in Haiku. The math functions are present in libroot. If you're trying to port, adapt the build system to account for that for the Haiku platform.

[kaliber]

Austin987 don't start from scratch, use ​http://svn.gna.org/viewcvs/pingwinek/trunk/packages/wine/wine-haiku-hacks.patch?rev=13063&view=markup Wine almost builds with gcc4, but Haiku is crashing (KDL). More work is needed to port wine to the Haiku.

[austin987]

Replying to kaliber:

Austin987 don't start from scratch, use ​http://svn.gna.org/viewcvs/pingwinek/trunk/packages/wine/wine-haiku-hacks.patch?rev=13063&view=markup Wine almost builds with gcc4, but Haiku is crashing (KDL). More work is needed to port wine to the Haiku.

Excellent, thanks!

I'll take a look when I get more time, and get some of these patches in upstream. Need to figure out the build system on Haiku, since the headers aren't being picked up:-/.

[austin987]

libm is _really_ prevalent and standard...Have you considered providing a compatibility library, instead of requiring all projects to adjust their build systems for haiku?

[pulkomandy]

Yes. And we won't. There is support for detecting if it's needed in all the project managers out there (autotools, scons, ...). Use it. Just remove the libm switch, note we are not incompatible with it at the source level. Only it's not needed to link to that explicitly.

[austin987]

Replying to pulkomandy:

Yes. And we won't. There is support for detecting if it's needed in all the project managers out there (autotools, scons, ...). Use it. Just remove the libm switch, note we are not incompatible with it at the source level. Only it's not needed to link to that explicitly.

Unfortunately, for wine, that's not an option: We can't use autoconf macros in winegcc, and I'm not going to add #ifdefs for every obscure platform that can't make a minimal effort to be compatible with mainstream.

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

Please consider reopening.

[pulkomandy]

I don't think we are planning on adding empty libs that do nothing just to help supporting half-done ports. Seems you're locked :)

[umccullough]

If you must, why not just create a symlink to support your porting effort?

[austin987]

I could, but this surely affects a bunch of other projects...and that's pretty hacky.

[anevilyak]

The vast majority of other projects use autotools and as such can more or less automatically adapt. This is the first time I've heard of a large scale project having such a restriction.

[scottmc]

In cases like this please don't go posting bugs on projects demanding that they fix something so that it works in Haiku. Please work with HaikuPorts (ports.haiku-files.org) to create a patch and have it reviewed prior to sending it upstream. We are minority OS and don't need to go around giving other projects a bad impression here.

<rant>We have politely fixed -lm issues with other projects who falsely assumed it to be some sort of standard to use -lm. Well it's NOT a standard, so they really shouldn't be treating it as such.</rant>

Looking through WINE's git, it appears they do in fact use autotools, so a simple AC_CHECK_LIB(cos,libm) (​http://tinyurl.com/neyxeb), and changing all cases of -lm to $LIBM should fix this right up.

[scottmc]

and as I always seem to do I got the AC_CHECK_LIB() backwards... it's AC_CHECK_LIB ( library, function, so in this case it'd be AC_CHECK_LIB(m, cos, LIBM="$LIBM -lm") or something similar.

[austin987]

Replying to scottmc:

In cases like this please don't go posting bugs on projects demanding that they fix something so that it works in Haiku. Please work with HaikuPorts (ports.haiku-files.org) to create a patch and have it reviewed prior to sending it upstream. We are minority OS and don't need to go around giving other projects a bad impression here.

There was no demand. Note, I work on wine and this was filed as an enhancement.

<rant>We have politely fixed -lm issues with other projects who falsely assumed it to be some sort of standard to use -lm. Well it's NOT a standard, so they really shouldn't be treating it as such.</rant>

Looking through WINE's git, it appears they do in fact use autotools, so a simple AC_CHECK_LIB(cos,libm) (​http://tinyurl.com/neyxeb), and changing all cases of -lm to $LIBM should fix this right up.

The problem is only partially in configure/configure.ac. The main problem is in tools/winegcc.c, which is a wrapper around gcc for compiling wine code, to avoid name conflicts and other problems compiling windows code brings about. Winegcc can't use autoconf macros, hence, the problem.

[phoudoin]

Replying to austin987:

Unfortunately, for wine, that's not an option: We can't use autoconf macros in winegcc, and I'm not going to add #ifdefs for every obscure platform that can't make a minimal effort to be compatible with mainstream.

The problem is only partially in configure/configure.ac. The main problem is in tools/winegcc.c, which is a wrapper around gcc for compiling wine code, to avoid name conflicts and other problems compiling windows code brings about. Winegcc can't use autoconf macros, hence, the problem.

But winegcc.c already does #ifdef and runtime conditional based on opts->target_platform in several places, for PLATFORM_APPLE, PLATFORM_SOLARIS and PLATFORM_WINDOWS!

I failed to see why Haiku platform should handle gracefully being considered PLATFORM_UNSPECIFIED when far more "mainstream" (your word) ones doesn't. In particular when the only changes needed for Haiku in winegcc.c, contrary to platforms above (Windows, on particular), seems to be quite limited.

In utils.h:

  39 enum target_platform
  40 {
  41     PLATFORM_UNSPECIFIED, PLATFORM_APPLE, PLATFORM_SOLARIS, PLATFORM_WINDOWS
>>>>     , PLATFORM_HAIKU
  42 };

And in winegcc.c:

 165 static const struct
 166 {
 167     const char *name;
 168     enum target_platform platform;
 169 } platform_names[] =
 170 {
 171     { "macos",   PLATFORM_APPLE },
 172     { "darwin",  PLATFORM_APPLE },
 173     { "solaris", PLATFORM_SOLARIS },
 174     { "mingw32", PLATFORM_WINDOWS },
 175     { "windows", PLATFORM_WINDOWS },
 176     { "winnt",   PLATFORM_WINDOWS },
>>>>     { "haiku",   PLATFORM_HAIKU }
 177 };
[...]
 223 #ifdef __APPLE__
 224 static enum target_platform build_platform = PLATFORM_APPLE;
 225 #elif defined(__sun)
 226 static enum target_platform build_platform = PLATFORM_SOLARIS;
 227 #elif defined(_WIN32)
 228 static enum target_platform build_platform = PLATFORM_WINDOWS;
>>>> #elif defined(__HAIKU__)
>>>> static enum target_platform build_platform = PLATFORM_HAIKU;
 229 #else
 230 static enum target_platform build_platform = PLATFORM_UNSPECIFIED;
 231 #endif
[...]
 921     if (!opts->nostdlib 
>>>>         && opts->target_platform != PLATFORM_HAIKU) 
 922     {
 923         strarray_add(link_args, "-lm");
 924         strarray_add(link_args, "-lc");
 925     }

Yes, libm (and libc, for that matter) are really prevalent on UNIX platforms. But is not a standard as in POSIX, just a de-facto one. And an "only UNIX" one. Windows is not Unix, and winegcc.c don't expect Windows platform to have libm and libc. As it doesn't expect MacOS X to have the same stack alignment constraint, or Solaris to support such align specification without relying on a temporary mapfile...

Haiku is not UNIX either, but you expect it to behave like one. Why? Because it's an "obscure" platform? Then does a port worth it?

If you want to support Haiku (that will be really nice, indeed), then *support* it, don't expect Haiku team to twist, bloat and adapt in order that Wine build transparently without any change.

Because next project not building out-of-the-box on Haiku will ask the same thing, and soon we'll fall in a portability trap. We tried hard to make ports way easier than with BeOS, adding a lot of POSIX stuff missing in BeOS. Being POSIX compliant don't make any platform an Unix one, just POSIX API compliant. We're still a non-Unix platform. We're still seeking to have a clean non-bloated system. We better do an unofficial port of a project ourself than twist/bloat Haiku so much to handle out-of-the-box *every* possible project. If such thing is even possible, which one will doubt for obvious reason.

Thanks to understand that.

[X512]

Mayble just option for ignoring "-lc -lm -lpthread" libraries in "ld" is enougth for solving this problem?

[umccullough]

Replying to X512:

Mayble just option for ignoring "-lc -lm -lpthread" libraries in "ld" is enougth for solving this problem?

This is a closed bug - please don't revive it to add more suggestions.

Anyhow, I'm pretty certain nobody is going to seriously hack nasty solutions to solve what is a porting issue.

If you're going to port the software, do it right. In most cases, this is a simple thing to resolve in the makefile.