Re: [Denemo-devel] A useful looking link for cross compiling... Re: gtk-app-devel-list Digest, Vol 105, Issue 20

[Jeremiah Benham]

I have just edited fluidsynth.mk. Now fluidsynth builds statically and denemo.exe no longer requires the dll. Unfortunately denemo.exe does not execute correctly in wine. I am wondering if it has something to do with the relocate stuff. I am already using --disable-binreloc but perhaps I should force -DWIN32 to the CFLAGS. Maybe you have different results in a real windows system. 

Jeremiah

On Mon, Feb 4, 2013 at 8:02 AM, Jeremiah Benham <address@hidden> wrote:

On Mon, Feb 4, 2013 at 6:34 AM, Richard Shann <address@hidden> wrote:

On Sun, 2013-02-03 at 14:09 -0600, Jeremiah Benham wrote:
> You can. Its all up there.

I have built the mxe default packages, which succeeded, and then added
the files I could see that you had extra into src and replaced
index.html with your version (as it seems, reading the Makefile that
this file is what is used to specify what can be built).
With this make denemo downloaded and built portmidi, downloaded
fluidsynth and the could not link

The failing link line was this:

libtool: link: i686-pc-mingw32-gcc -mms-bitfields -O2
-fomit-frame-pointer -funroll-all-loops -finline-functions -Wall -W
-Wpointer-arith -Wbad-function-cast -Wcast-qual -Wcast-align
-Wstrict-prototypes -Winline -Wno-unused-parameter -Wno-cast-qual
-Wl,--as-needed -o fluidsynth.exe
fluidsynth-fluidsynth.o  ./.libs/libfluidsynth.a -lreadline
-L/home/rshann/mxe/usr/i686-pc-mingw32/lib /home/rshann/mxe/usr/i686-pc-mingw32/lib/libportaudio.a -lwinmm -ldsound /home/rshann/mxe/usr/i686-pc-mingw32/lib/libgthread-2.0.a /home/rshann/mxe/usr/i686-pc-mingw32/lib/libglib-2.0.a -lws2_32 -lole32 -lshlwapi /home/rshann/mxe/usr/i686-pc-mingw32/lib/libpcre.a /home/rshann/mxe/usr/i686-pc-mingw32/lib/libintl.a /home/rshann/mxe/usr/i686-pc-mingw32/lib/libiconv.a -lpthread
fluidsynth-fluidsynth.o:fluidsynth.c:(.text+0x41): undefined reference
to `_imp__new_fluid_cmd_handler'


There is no patch for fluidsynth (right?). Is the flag --disable-realine
in fluidsynth.mk a typo for --disable-readline?

Yes. This you are correct. I had to use cmake to install fluidsynth. What you downloaded was my attempt to compile it using autotools. Can you download it again or delete the autoconf stuff and uncomment the cmake instructions. There is still one problem (I think). This is the only library that appears to be dynamically linking. If the resulting dll is not in the bin dir along with denmeo (when executing), denemo complains that it can't find libfluidsynth.dll. 

>  I had to cp and rename evince's pkg-config file but that should be
> all you have to do other then patches.

There is also one other hack I had to do. I had to copy the portmidi headers into mxe include directory so that denemo can find them when compiling. The reason for this is because I am using the portmidi that I packaged for gub using autotools instead of cmake. I could probably use the official package but I need to first learn to disable the building of the java stuff (pmdefaults I think).
 

Can you give more detail here? Copying pkg-config from where to where?
(Not that I have hit that yet)

to find the destination go to your mxe folder and type:
find ./ -name '*.pc'
I had to pipe that through grep to find the pkg-config with a similar name to file that it was looking for.

Jeremiah

Richard

>  The patches are in the src dir named like this
> evince-1-descrption.patch. the system knows it is to be patched simply
> by the presence of the patch file.
>
> Jeremiah
>
> On Feb 3, 2013 11:04 AM, "Richard Shann" <address@hidden>
> wrote:
>         On Sun, 2013-02-03 at 10:38 -0600, Jeremiah Benham wrote:
>         > Yes. Evince required a few patches to get compiled.
>         That's fantastic news! I take it the files like
>         http://denemo.org/~jjbenham/mxe/src/evince.mk
>
>         are the ones you have developed to do this? Shall I try to
>         repeat the
>         build on my machine and then I can copy them across to some
>         windows
>         machines and test them?
>
>         >  Would I look into using nsis now or would I put everyhing
>         into a
>         > zipped directory?
>         For testing we can just zip them, I would guess nsis will be
>         the easiest
>         way of getting something we can give users.
>
>         Richard
>
>