denemo-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Denemo-devel] [bug #46868] Missing .DLL files in downloads


From: Jeremiah Benham
Subject: Re: [Denemo-devel] [bug #46868] Missing .DLL files in downloads
Date: Tue, 12 Jan 2016 09:29:56 -0600


On Jan 12, 2016 2:46 AM, "Richard Shann" <address@hidden> wrote:
>
> On Tue, 2016-01-12 at 00:35 -0600, Jeremiah Benham wrote:
> > Do you want me to compile LilyPond? We may be able to debug what is
> > going on. If we copy the LilyPond directory, we would add about 50mb
> > to the zip file. If we know what essential files that would need
> > copying over we could go that route also. I could not get it to
> > execute denemo in wine for some reason. I will have to try it again.
> > What do you suggest?
> I wonder if the build machine should be running lilydev (as this would
> leverage the effort the LilyPond folk put in to maintain an environment
> that builds LilyPond).

I think lilydev is too old for our needs. Even the LilyPond people working on gun have moved to the latest 64 bit ubuntu.

>I didn't realize you weren't building LilyPond -
> how is the current zip file created?
>

I stopped building it when there were reports of it crashing. I left it out because I thought you were going to create a script to copy the official LilyPond files over. I can have gub compile it again it may be something trivial to fix if I only knew what was causing the crash. I commented out LilyPond cairo as a dependency of Denemo. That means gub does not compile it. Creating the zip file is just a script that creates a directory with the root prefix of the Denemo directory and a .bat file added to execute it. I don't think the official LilyPond is compiled with cairo support. When we compiled denemo we have it compiled with cairo support. I am not sure if this is needed or why it is needed if so. It could be crashing just from missing a file. I notice if all the files from /etc are not there it will crash. I don't know if that is the case or not when we compile LilyPond.

Jeremiah

> Richard
>
> >
> > Jeremiah
> >
> > On Jan 11, 2016 1:14 PM, "Richard Shann" <address@hidden>
> > wrote:
> >         I see that libgcc_... is now present in /usr/bin on the 11 Jan
> >         build and
> >         (as always) it executes on the 32-bit Vista box I have access
> >         to. No
> >         progress with LilyPond though - do you have an idea about how
> >         to fix
> >         this?
> >
> >         Richard
> >
> >
> >
> >         On Sun, 2016-01-10 at 12:05 -0600, Jeremiah Benham wrote:
> >         > I will look into compiling it statically. I saw that it was
> >         compiled
> >         > and installed but it was not packaged up when creating the
> >         mingw
> >         > binary. I wrote a few lines in the routine for creating the
> >         mingw
> >         > package to copy the two files into the temp file it creates
> >         before
> >         > zipping it all up.  It is building now.
> >         >
> >         >
> >         > It could have also been caused by my removing the lilypond
> >         depenedency
> >         > for gub. This way it does not build the lilypond that was
> >         crashing
> >         > anyway. Do you still want to copy the entire lilypond folder
> >         over?
> >         >
> >         >
> >         > Jeremiah
> >         >
> >         >
> >         > On Sun, Jan 10, 2016 at 10:26 AM, Richard Shann
> >         > <address@hidden> wrote:
> >         >         Follow-up Comment #1, bug #46868 (project denemo):
> >         >
> >         >         I've looked in the 28th Jan zip file and the
> >         gcc_s... dll
> >         >         library is present
> >         >         in the bin directory.
> >         >         Both this and the later zip versions all run fine on
> >         a 32-bit
> >         >         Windows Vista
> >         >         machine, so I'm not sure why some machines need it
> >         and some
> >         >         don't. I found a
> >         >         link to this subject
> >         >
> >          http://stackoverflow.com/questions/12921911/mingw-libgcc-s-sjlj-1-dll-is-missing
> >         >         which seems to indicate two possibilities - either a
> >         flag
> >         >         needed at link time
> >         >         or a switch from 64 bit to 32 bit mingw compiler.
> >         >         Here are the relevant bits:
> >         >
> >         >         You have to use -static-libgcc while compiling with
> >         mingw’s g
> >         >         ++ to elemenate
> >         >         the dependacy on LIBGCC_S_SJLJ-1.DLL. You can do
> >         that by
> >         >         adding static-libgcc
> >         >         to the linker flags.
> >         >
> >         >         I found this info in this post:
> >         >
> >          http://www.qtcentre.org/threads/39639-MinGW-w64-dependency-on-LIBGCC_S_SJLJ-1-DLL
> >         >
> >         >         thanks for the link, that wasn't my problem but i
> >         saw in the
> >         >         link, that this
> >         >         description is for mingw 64. this pointed me in the
> >         right
> >         >         direction. i
> >         >         compiled the program using the 32 bit mingw compiler
> >         instead
> >         >         of the 64 bit
> >         >         compiler.
> >         >
> >         >
> >          _______________________________________________________
> >         >
> >         >         Reply to this item at:
> >         >
> >         >           <http://savannah.gnu.org/bugs/?46868>
> >         >
> >         >         _______________________________________________
> >         >           Message sent via/by Savannah
> >         >           http://savannah.gnu.org/
> >         >
> >         >
> >         >         _______________________________________________
> >         >         Denemo-devel mailing list
> >         >         address@hidden
> >         >         https://lists.gnu.org/mailman/listinfo/denemo-devel
> >         >
> >         >
> >         >
> >
> >
>
>


reply via email to

[Prev in Thread] Current Thread [Next in Thread]