I'm working on a PR for libsamplerate to build native MinGW packages.
Initially I stuck with the autotools build but for some reason '-z' was
sneaking into the LDFLAGS and I couldn't figure out how to remove it.
So then I decided to transition to a CMake build which is working including
tests, th
On Tue, Sep 13, 2022 at 8:08 AM Greg Hellings
wrote:
> I thought those didn't support generic applications and could only run
> apps from the Microsoft store?
>
I don't know much about it, but this guy has had some luck building
software for himself...
https://github.com/drowe67/freedv-gui/issu
On Thu, May 9, 2019 at 5:44 PM Sandro Mani wrote:
>
> On 10.05.19 00:36, Richard Shaw wrote:
> > I maintain a few packages in my COPR[1] that I need for a project I'm
> > a developer on and I actually produce the Windows installer on my
> > Fedora machine using
I maintain a few packages in my COPR[1] that I need for a project I'm a
developer on and I actually produce the Windows installer on my Fedora
machine using CMake/NSIS.
Thought I would ask if there's interest in doing reviews to get these in
Fedora proper:
portaudio
sndfile
speexdsp
libsamplerate
Ok, now I'm confused... What's the purpose of having a group that's not
user visible?
Thanks,
Richard
___
mingw mailing list -- mingw@lists.fedoraproject.org
To unsubscribe send an email to mingw-le...@lists.fedoraproject.org
Fedora Code of Conduct: http
Any packages that should also be included besides the ones mention in the
wiki? (Whether required or optional?)
Like mingw32-nsis?
Thanks,
Richard
___
mingw mailing list -- mingw@lists.fedoraproject.org
To unsubscribe send an email to mingw-le...@lists.
Let me know if there's anything I can do to help.
Thanks,
Richard
___
mingw mailing list -- mingw@lists.fedoraproject.org
To unsubscribe send an email to mingw-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.ht
I've had my stuff installed for so long I hadn't thought about it until I
was stepping someone else through the process of getting a basic mingw
build system setup from scratch, but...
What would it take to have a group added to dnf just to install all the
"stuff" you're almost always going to nee
On Mon, Jan 16, 2017 at 8:04 AM, Greg Hellings
wrote:
> What phase of the build are you getting this message in?
>
make package. I'm using the GetPrerequisites module to pull in the needed
DLL's but it's not finding them anyway.
I've even tried using the part of the GET_PREREQUISITES function
Never mind The ";"'s are suppressed in the output, back to the drawing
board...
Thanks,
Richard
___
mingw mailing list -- mingw@lists.fedoraproject.org
To unsubscribe send an email to mingw-le...@lists.fedoraproject.org
I'm working on a new mingw32 build of a project I help develop and I'm
running into an issue building the installer because it can't find libgcc:
warning: target 'libgcc_s_sjlj-1.dll' is not absolute...
warning: target 'libgcc_s_sjlj-1.dll' does not exist...
Which is present
$ locate libgcc_s_sjl
I was trying to create a new NSIS package for something I have packaged
before. It's probably been almost a year and I'm sure a number of the mingw
packages have been updated but I'm not sure what's causing this:
Run CPack packaging tool...
CPack: Create package using NSIS
CPack: Install projects
I'm not ready to submit it for review but I recently built my own
mingw-fltk packages for 32 and 64bit.
I ended up having to use the cmake build as getting the autotools build
working wasn't going well. They use some manual makesfiles to kick things
off that didn't play nicely with mingw-configure
On Thu, Nov 21, 2013 at 3:41 AM, Erik van Pienbroek wrote:
> Richard Shaw schreef op wo 20-11-2013 om 22:01 [-0600]:
> > I had tried a few combinations of libtoolize but hadn't tried --force,
> > but no dice, same error...
> >
> >
> > /bin/sh ../libtool --t
On Wed, Nov 20, 2013 at 12:52 PM, Erik van Pienbroek
wrote:
> Richard Shaw schreef op do 17-10-2013 om 11:48 [-0500]:
>
> > I can now get it to build an RPM but it will not build the shared
> > library with libtool complaining about:
> >
> >
> > libtool:
I'm trying to verify that the required symbols are in the library since
libusb-compat is really designed to build against libusb, not libusbx. I've
gotten this far:
$ x86_64-w64-mingw32-nm -uC libusb_la-core.o
U atexit
U fprintf
U fputc
U free
U _imp___
OK, still learning a bit here...
I assume that mingw projects are supposed to use the host libtool?
I noticed that the current mingw package intentionally doesn't package it
when I created my own libltdl package for mingw64.
Richard
___
mingw mailing l
Still not having any luck...
/bin/sh ../libtool --tag=CC --mode=link i686-w64-mingw32-gcc
-fvisibility=hidden -std=gnu99 -fgnu89-inline -Wall -Wundef -Wunused
-Wstrict-prototypes -Werror-implicit-function-declaration -Wno-pointer-sign
-Wshadow -I/usr/i686-w64-mingw32/sys-root/mingw/include/libu
I thinkI understand why libusb 0.1 (libusb-compat) is not already
available! :) I'm trying to build it as a dependency for hamlib which is
only compatible with the old API.
After a lot of hand patching from various sources google pointed me to I
can now get it to build an RPM but it will not build
On Mon, May 20, 2013 at 5:14 PM, Steven Boswell II wrote:
> Well, you're going to need a programmer to fix that one.
>
> You're also going to need symbols. Make a debug build of your program,
> and install debug symbols for the packages you're using. Usually they're
> in packages called "debugin
Ok, getting a little closer... I guess I should have warned you I'm a
packager but not a programmer so my knowledge of gdb probably wouldn't
qualify as "rudimentary".
Here's a link to the full output. I just kept hitting 'n' until it exited..
http://pastebin.com/AZtTtq1s
Thanks,
Richard
On Mon, May 20, 2013 at 3:05 PM, Steven Boswell II wrote:
> In my experience, if you run your program with gdb, and type "break abort"
> before you type "run", gdb will catch the problem.
>
Thanks for the tip!
Here's the output:
This GDB was configured as "i686-pc-mingw32".
For bug reporting ins
Hopefully someone can give me a hint here...
I'm working on converting a project[1] from a patchwork of autotools to
cmake based build. I've got the cross-compiling working and even managed to
create an installer using cpack with NSIS after figuring out which DLLs I
needed to package with it.
The
Figured it out... I was missing -lwinmm. Sorry for the noise.
Richard
___
mingw mailing list
mingw@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/mingw
Ok, it looks like I got it a little backwards... It's not the -l... that's
missing, it's the -I...
Apparently mingw32-cmake creates a separate includes
file, includes_CXX.rsp, whereas the native cmake just puts them in the
flags.cmake file.
During compilation, it doesn't appear the contents of in
Sorry if this has already been covered but my google-fu hasn't gotten me
anywhere.
I'm trying to cross compile a project I've helped develop a cmake
configuration for since the autotools one doesn't work for all platforms
currently.
I've had luck cross compiling all the dependencies but when I tr
26 matches
Mail list logo
