wine-crossover-games 8.0.0_1 doesn't compile on snow leopard

[ifigueroap@…]

I've installed all the dependencies using the universal variant... Here is the output of port install -d

--->  Computing dependencies for wine-crossover-games
--->  Configuring wine-crossover-games
Error: Target org.macports.configure returned: configure failure: shell command " cd "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_x11_wine-crossover-games/work/wine" && ./configure --prefix=/opt/local --x-include=/opt/local/include --x-lib=/opt/local/lib " returned error 77
Command output: checking build system type... i386-apple-darwin10.2.0
checking host system type... i386-apple-darwin10.2.0
checking whether make sets $(MAKE)... yes
checking for gcc... /usr/bin/gcc-4.2
checking for C compiler default output file name... 
configure: error: in `/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_x11_wine-crossover-games/work/wine':
configure: error: C compiler cannot create executables
See `config.log' for more details.

I attach the config.log file

[ifigueroap@…]

Replying to ifigueroap@…:

Observation: I _can_ install other ports with my current configuration

I've installed all the dependencies using the universal variant... Here is the output of port install -d

--->  Computing dependencies for wine-crossover-games
--->  Configuring wine-crossover-games
Error: Target org.macports.configure returned: configure failure: shell command " cd "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_x11_wine-crossover-games/work/wine" && ./configure --prefix=/opt/local --x-include=/opt/local/include --x-lib=/opt/local/lib " returned error 77
Command output: checking build system type... i386-apple-darwin10.2.0
checking host system type... i386-apple-darwin10.2.0
checking whether make sets $(MAKE)... yes
checking for gcc... /usr/bin/gcc-4.2
checking for C compiler default output file name... 
configure: error: in `/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_x11_wine-crossover-games/work/wine':
configure: error: C compiler cannot create executables
See `config.log' for more details.

I attach the config.log file

[ifigueroap@…]

Cc Me!

[jeremyhu (Jeremy Huddleston Sequoia)]

Ryan, this looks like it came from your change:

 configure.ldflags-append \
     -framework CoreServices \
+    -lfreetype \
+    -lwine \
     -lz

[jeremyhu (Jeremy Huddleston Sequoia)]

Cc Me!

[jeremyhu (Jeremy Huddleston Sequoia)]

r60828 ... wine-devel doesn't have this... I'm not sure why it's there...

[ryandesign (Ryan Carsten Schmidt)]

I must've had another version of wine installed already, providing libwine.dylib.

I added both those lines because it wouldn't build without them. I'll have to go back and re-try the build and find those error messages for you...

[ryandesign (Ryan Carsten Schmidt)]

Without -lfreetype I have:

/usr/bin/gcc-4.2 -m32 -L/opt/local/lib -framework CoreServices -lz  ../tools/sfnt2fnt.o   -o ../tools/sfnt2fnt
Undefined symbols:
  "_FT_Init_FreeType", referenced from:
      _main in sfnt2fnt.o
  "_FT_New_Face", referenced from:
      _main in sfnt2fnt.o
  "_FT_Get_Char_Index", referenced from:
      _main in sfnt2fnt.o
  "_FT_Get_Sfnt_Name", referenced from:
      _main in sfnt2fnt.o
  "_FT_Get_Sfnt_Name_Count", referenced from:
      _main in sfnt2fnt.o
  "_FT_Library_Version", referenced from:
      _main in sfnt2fnt.o
  "_wine_cp_get_table", referenced from:
      _main in sfnt2fnt.o
      _main in sfnt2fnt.o
  "_FT_Get_Sfnt_Table", referenced from:
      _main in sfnt2fnt.o
  "_FT_Done_Face", referenced from:
      _main in sfnt2fnt.o
  "_FT_Load_Char", referenced from:
      _main in sfnt2fnt.o
      _main in sfnt2fnt.o
      _main in sfnt2fnt.o
      _main in sfnt2fnt.o
  "_FT_Get_First_Char", referenced from:
      _main in sfnt2fnt.o
  "_FT_Set_Pixel_Sizes", referenced from:
      _main in sfnt2fnt.o
ld: symbol(s) not found

With -lfreetype but without -lwine I get:

/usr/bin/gcc-4.2 -m32 -L/opt/local/lib -framework CoreServices -lfreetype -lz  ../tools/sfnt2fnt.o   -o ../tools/sfnt2fnt
Undefined symbols:
  "_wine_cp_get_table", referenced from:
      _main in sfnt2fnt.o
      _main in sfnt2fnt.o
ld: symbol(s) not found

And with both -lfreetype and -lwine I now see the same configure failure reported in this ticket, when I have no wine port installed.

I apparently missed that version 8.1.0 is already available. I'll see if that helps.

[jeremyhu (Jeremy Huddleston Sequoia)]

If not, let me know, and I'll take a closer look... the "correct" fix is to put those in at the Makefile.am level

[ryandesign (Ryan Carsten Schmidt)]

8.1.0 has the same issue.

It seems it's trying to compile this sfnt2fnt earlier:

/usr/bin/gcc-4.2 -m32 -O2 -arch i386 -o sfnt2fnt sfnt2fnt.o -L../libs/wine -lwine ../libs/port/libwine_port.a -L/opt/local/lib -framework CoreServices -lz -L../../freetype/patentobjs/.libs -L../../freetype/objs/.libs -lcxfreetype && install_name_tool -change @executable_path/`../tools/relpath /opt/local/bin /opt/local/lib`/libwine.1.dylib @executable_path/../libs/wine/libwine.1.dylib sfnt2fnt || rm -f sfnt2fnt

But this fails:

ld: library not found for -lcxfreetype
collect2: ld returned 1 exit status

Because of the "|| rm -f sfnt2fnt" it proceeds on despite the error, and then fails on some later dependent of sfnt2fnt that tries to build it again but doesn't pass it all the compile options it needs.

libcxfreetype.dylib gets built by the copy of freetype included with the wine-crossover-games source. We could create a freetype-crossover-games port​ for that and update wine-crossover-games to use it​. But the problem is that while crossover's version of freetype installs a library with a different name, it still wants to install includes and pkgconfig files of the same name as the freetype port's. So we would either need to mark the two freetypes as conflicting (not viable because nobody using wine-crossover-games could then use any port depending on the regular freetype -- including fontconfig, which wine-crossover-games depends on) or not install the headers or pkgconfig files (don't know if wine-crossover-games would still be able to find it then) or go to some effort to further modify crossover's freetype to also rename the includes and pkgconfig files.

The differences between the standard freetype and crossover's version​ don't seem that great. It might be better to have wine-crossover-games continue to use the normal freetype, and just patch it to recognize normal freetype's libfreetype.dylib instead of the libcxfreetype.dylib it's looking for.

Reviewing the commit where I updated the port to 8.0.0, I see one change I made had an inadvertent consequence. I removed these lines:

post-extract {
	system "cd ${workpath} && mv sources/wine ."
}

I didn't understand why the portfile hadn't previously just used "worksrcdir sources/wine", and the 8.0.0 sources dispensed with the "sources" directory so the existing "worksrcdir wine" was sufficient. I now realize that the wine source looks for the freetype source at a relative path to its own, and if it finds it, it adds these -lcxfreetype flags; see this part of configure.ac:

    if test -d "$srcdir/../freetype"
    then
        dnl Use the CrossOver in-tree freetype library
        ac_freetype_incl="-I$srcdir/../freetype/include"
        ac_freetype_libs="-L../freetype/patentobjs/.libs -L../freetype/objs/.libs -lcxfreetype"
        ft_lib=yes
    fi

You previously made those tests fail by moving the wine source; I made them now succeed by keeping the wine source where it was, thereby introducing this problem.

A fix is another change I wanted to make anyway: instructing MacPorts to only extract the wine directory​ and not the other directories that we don't need anyway. This will speed up the extract step too. And I think this is the solution we should use. Any objections?

[jeremyhu (Jeremy Huddleston Sequoia)]

Yeah, your final solution seems best to me. It will have the effect of using freetype. It doesn't look like there's anything of real consequence between the two freetype versions, but if there is, we can patch freetype appropriately and send the changes upstream.

[ryandesign (Ryan Carsten Schmidt)]

Committed in r61735.

[ifigueroap@…]

it works now, thanks a lot