search for: jon_i

Displaying 19 results from an estimated 19 matches for "jon_i".

Did you mean: joni
2012 Feb 04
0
flac-dev Digest, Vol 87, Issue 10
On Sun, Feb 5, 2012 at 1:30 AM, <flac-dev-request at xiph.org> wrote: > Send flac-dev mailing list submissions to > flac-dev at xiph.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://lists.xiph.org/mailman/listinfo/flac-dev > or, via email, send a message with subject or body 'help' to > flac-dev-request at xiph.org
2010 Jan 06
0
FLAC C API / Visual Studio 2008 FILE* Issue
Now that you mention it I remember many years ago having a compatibility issue with some app we'd written. As I recall we had to get our customers to install msvcr70.dll because none of their machines had it (this was in the days of NT4). That dll came with the version of Visual Studio we were using but of course none of our customers had Visual Studio installed! I guess Microsoft is off
2012 Mar 25
2
Trying to link against libFLAC_static.lib (windows)
On Fri, Mar 23, 2012 at 9:45 PM, JonY <jon_y at users.sourceforge.net> wrote: > On 3/23/2012 13:59, Glenn McCord wrote: >> Hi. I'm trying to get a project linking to libFLAC_static.lib but I >> get linker errors such as the following. >> >> The __imp__ prefix seems to imply that some kind of .dll usage is >> happening, which it shouldn't. >>
2010 Jan 06
2
FLAC C API / Visual Studio 2008 FILE* Issue
On 1/6/2010 18:53, Stuart Fisher wrote: > I haven't done any FLAC development for some time now, but I've around 25 years experience of working with libc and I don't really agree with Ben's view. > > You're talking about a binary compatibility issue and I'd be surprised if Microsoft had changed something in the library to break it. OS companies usually only break
2012 Mar 23
2
Trying to link against libFLAC_static.lib (windows)
Hi. I'm trying to get a project linking to libFLAC_static.lib but I get linker errors such as the following. 6>AudioDecoder.lib(CFlacDecoder.obj) : error LNK2019: unresolved external symbol __imp__FLAC__stream_decoder_process_until_end_of_metadata referenced in function "protected: int __thiscall CFlacDecoder::CreateDecoder(void)" (?CreateDecoder at CFlacDecoder@@IAEHXZ)
2011 Nov 14
0
Git branch with compiling fixes for win32
On 11/10/2011 19:22, JonY wrote: > On 11/10/2011 18:39, Erik de Castro Lopo wrote: >> >> I'm subscribed to the list (and I set my reply-to to the list). >> Please do not CC me. >> >> JonY wrote: >> >>> Its probably on one of the sf tracker somewhere, I can't seem to find it >>> anymore. It wasn't anything complicated, so I should
2011 Nov 26
0
Git branch with compiling fixes for win32
On 11/16/2011 06:49, JonY wrote: > On 11/16/2011 03:20, Erik de Castro Lopo wrote: >> JonY wrote: >> >>> On 11/14/2011 18:01, JonY wrote: >>>> On 11/10/2011 19:22, JonY wrote: >>>>> On 11/10/2011 18:39, Erik de Castro Lopo wrote: >>>>>> >>>>>> I'm subscribed to the list (and I set my reply-to to the list).
2012 Feb 02
0
Git branch with compiling fixes for win32
On 2/1/2012 22:36, JonY wrote: > On 2/1/2012 18:52, Erik de Castro Lopo wrote: >> JonY wrote: >> >>> Alright, here's a quick fix, although it is more ugly than I remembered. >>> >>> Basically, it removes those _MSC_VER ifdefs, and relies on inttypes.h >>> where available, and falls back to I64 on MSVC and then ll for others, >>> all
2012 Feb 02
0
Git branch with compiling fixes for win32
On 2/3/2012 02:50, Erik de Castro Lopo wrote: > JonY wrote: > >> Attached patch builds without any warnings for MinGW. > > Sorry JonY, that patch does not apply against current git master > which is here: > > https://git.xiph.org/?p=flac.git;a=summary > > Specifically I pulled out much of the "#ifdef _MSC_VER" printf stuff > in this commit:
2012 Feb 04
1
Git branch with compiling fixes for win32
On 2/3/2012 06:33, JonY wrote: > On 2/3/2012 02:50, Erik de Castro Lopo wrote: >> JonY wrote: >> >>> Attached patch builds without any warnings for MinGW. >> >> Sorry JonY, that patch does not apply against current git master >> which is here: >> >> https://git.xiph.org/?p=flac.git;a=summary >> >> Specifically I pulled out much
2012 Feb 04
0
Moving CPP hackery
On 2/4/2012 13:20, Erik de Castro Lopo wrote: > Hi all, especially David Yeo and JonY, > > I've started moving compiler specific CPP hacker into a separate file > at include/share/compat.h. > > Eventually I hope to be able to move all of the require CPP hackery > for $random_compiler into this file and have any C file which needs > any compiler specific tweak to
2012 Mar 23
0
Trying to link against libFLAC_static.lib (windows)
On 3/23/2012 13:59, Glenn McCord wrote: > Hi. I'm trying to get a project linking to libFLAC_static.lib but I > get linker errors such as the following. > > The __imp__ prefix seems to imply that some kind of .dll usage is > happening, which it shouldn't. > > All I need is the C lib, so I just build libFLAC_static from within > VS2010 (I've converted the
2011 Nov 10
2
Git branch with compiling fixes for win32
On 11/10/2011 08:02, Erik de Castro Lopo wrote: > JonY wrote: > >> I submitted a patch sometime ago to correct printf specifiers for win32 >> by using inttypes.h, but there were no response, so I thought flac >> development was dead. > > Development is probably complete. Maintenance should continue. > >> Not sure where the patch went or if its still valid.
2011 Nov 09
4
Git branch with compiling fixes for win32
On 11/10/2011 06:58, Erik de Castro Lopo wrote: > Sven-Hendrik Haase wrote: > >> Si se?or: http://code.entropywave.com/git/flac.git > > Ok, there are about 6 commits there. Over the weekend I'll > have a look at them and if they're fine, I'll push them to > the Xiph Git repo. > > If anyone else has Flac patches that they would like to > see commited
2012 Mar 26
0
Trying to link against libFLAC_static.lib (windows)
On 3/26/2012 06:52, Glenn McCord wrote: >> >> Did you compile the dll earlier? If so, you can try cleaning the project >> and rebuilding. > > I've compiled the .dll earlier, but they've now all been deleted. They > would have been built when I built the entire solution (and thus all > the projects). I've subsequently deleted them and just built the >
2011 Nov 15
2
Git branch with compiling fixes for win32
On 11/16/2011 03:20, Erik de Castro Lopo wrote: > JonY wrote: > >> On 11/14/2011 18:01, JonY wrote: >>> On 11/10/2011 19:22, JonY wrote: >>>> On 11/10/2011 18:39, Erik de Castro Lopo wrote: >>>>> >>>>> I'm subscribed to the list (and I set my reply-to to the list). >>>>> Please do not CC me. >>>>>
2011 Nov 15
2
Git branch with compiling fixes for win32
On 11/14/2011 18:01, JonY wrote: > On 11/10/2011 19:22, JonY wrote: >> On 11/10/2011 18:39, Erik de Castro Lopo wrote: >>> >>> I'm subscribed to the list (and I set my reply-to to the list). >>> Please do not CC me. >>> >>> JonY wrote: >>> >>>> Its probably on one of the sf tracker somewhere, I can't seem to find it
2012 Feb 01
3
Git branch with compiling fixes for win32
On 2/1/2012 18:52, Erik de Castro Lopo wrote: > JonY wrote: > >> Alright, here's a quick fix, although it is more ugly than I remembered. >> >> Basically, it removes those _MSC_VER ifdefs, and relies on inttypes.h >> where available, and falls back to I64 on MSVC and then ll for others, >> all format warnings suppressed. > > JonY, > > Sorry
2011 Nov 10
5
Git branch with compiling fixes for win32
On 11/10/2011 18:39, Erik de Castro Lopo wrote: > > I'm subscribed to the list (and I set my reply-to to the list). > Please do not CC me. > > JonY wrote: > >> Its probably on one of the sf tracker somewhere, I can't seem to find it >> anymore. It wasn't anything complicated, so I should be able to redo it >> quickly. > > I'm a Linux