http://gabriel.mp3-tech.org/lametest.zip
(updated)
Full Version: Lame GCC 3.1 compile
No one willing to try?
"Unable to find library cygncurses6.dll"
Oh, well that message only appears when using lame-3.1-opt-nasm.exe
So, here are my results:
(Athlon XP 1500+, 384Mb RAM)
Gabriel GCC 3.1 compile lame-3.1-nasm.exe: 39 sec to encode a 3:20 song using default parameters. (lame <filename.wav>)
Mitiok ICL 6.0 compile: 30sec to encode the same song, using same parameters.
Just for reference: Gabriel GCC 2.95 compile takes 44sec
Regards;
Roberto.
So, here are my results:
(Athlon XP 1500+, 384Mb RAM)
Gabriel GCC 3.1 compile lame-3.1-nasm.exe: 39 sec to encode a 3:20 song using default parameters. (lame <filename.wav>)
Mitiok ICL 6.0 compile: 30sec to encode the same song, using same parameters.
Just for reference: Gabriel GCC 2.95 compile takes 44sec
Regards;
Roberto.
I added the ncurses dll
lame-2.95: 7.4434x
lame-3.1: 7.8929x
lame-3.1-nasm: 8.2274x
lame (mitiok's): 10.854x
You should try compiling with MinGW, maybe the files would be faster when they didn't need Cygwin libraries.
lame-3.1: 7.8929x
lame-3.1-nasm: 8.2274x
lame (mitiok's): 10.854x
You should try compiling with MinGW, maybe the files would be faster when they didn't need Cygwin libraries.
Does 3.1-opt-nasm improve speed over 3.1-nasm?
Hello!
I wrote to the lame mailing list a few days ago,
asking for help compiling lame with gcc.
nobody answered yet.
could you tell how you did it ?
results:(Athlon650)
lame-2.95 :2.1522
lame-3.1 :2.2527
lame-3.1-nasm :2.3012
lame-3.1-opt-nasm :2.3140
lame-mitiok :3.2994
lame-rocko :3.3291
lame-rocko is an ICL4.5 compile without compatibility-code for Pentium1.
bye, rocko
I wrote to the lame mailing list a few days ago,
asking for help compiling lame with gcc.
nobody answered yet.
could you tell how you did it ?
results:(Athlon650)
lame-2.95 :2.1522
lame-3.1 :2.2527
lame-3.1-nasm :2.3012
lame-3.1-opt-nasm :2.3140
lame-mitiok :3.2994
lame-rocko :3.3291
lame-rocko is an ICL4.5 compile without compatibility-code for Pentium1.
bye, rocko
Why I keep getting the "config.h not found" message when compiling using MinGW?
William, the simplest thing for you to do is to copy configMS.h to config.h. Alternatively, edit your makefile to do it for you.
Thanks john 
But now I have another problem when compiling:
What does it mean and how can I solve it?
edit: By the way, I use Makefile.DJGPP.
But now I have another problem when compiling:
QUOTE
libmp3lame/libmp3lame.a(set_get.o)(.text+0x1029):set_get.c: undefined reference
to `apply_preset'
make: *** [lame] Error 1
to `apply_preset'
make: *** [lame] Error 1
What does it mean and how can I solve it?
edit: By the way, I use Makefile.DJGPP.
rocko_k, if you want to use the MinGW32 version of GCC3.1, you can pick up a zip here that contains a makefile and batch file that will do the job for you.
Both should be placed in the lame root directory, and the 'lame.exe' will be placed in the 'frontend' dir when compiled. You will need to edit the makefile and the batch file to point to the correct source directories for your lame and MinGW installations, and to indicate if you have nasm and where it is. You may also need to edit the 'arch' parameter to reflect the processor type that you have. Apart from that, just run the batch file and sit back and wait for it to finish!!
Both should be placed in the lame root directory, and the 'lame.exe' will be placed in the 'frontend' dir when compiled. You will need to edit the makefile and the batch file to point to the correct source directories for your lame and MinGW installations, and to indicate if you have nasm and where it is. You may also need to edit the 'arch' parameter to reflect the processor type that you have. Apart from that, just run the batch file and sit back and wait for it to finish!!
William, I think that the makefile may need to be updated to include 'libmp3lame/presets.c' in the compile? Try it and see.
'presets.c' was added to the library after the last time that the DJGPP makefile was updated.
'presets.c' was added to the library after the last time that the DJGPP makefile was updated.
Thanks again John
I downloaded your makefile and compiled LAME with the default arch because I have an Athlon 1.2GHz. However the performance is much slower than mitiok's compile.
I tested with a 5:30 song, with default parameters:
LAME-MinGW: 7.9354x
LAME-mitiok: 10.250x
I downloaded your makefile and compiled LAME with the default arch because I have an Athlon 1.2GHz. However the performance is much slower than mitiok's compile.
I tested with a 5:30 song, with default parameters:
LAME-MinGW: 7.9354x
LAME-mitiok: 10.250x
Yep, my own GCC3.1 lame compile is similarly slower than my ICL compile.
Thank You, john33 !
I will try your makefile soon.
Another test for Gabriel, now with the lame default settings:
The previous test was done with "--alt-preset fast standard".
The difference between nasm and opt-nasm is now more obvious.
results: (Athlon650)
lame-2.95 :3.9509
lame-3.1 :4.1401
lame-3.1-nasm :4.3261
lame-3.1-opt-nasm :4.6194
lame-mitiok :5.7248
lame-rocko :5.9620
bye, rocko
I will try your makefile soon.
Another test for Gabriel, now with the lame default settings:
The previous test was done with "--alt-preset fast standard".
The difference between nasm and opt-nasm is now more obvious.
results: (Athlon650)
lame-2.95 :3.9509
lame-3.1 :4.1401
lame-3.1-nasm :4.3261
lame-3.1-opt-nasm :4.6194
lame-mitiok :5.7248
lame-rocko :5.9620
bye, rocko
To compile under cygwin I just did
./configure --enable-nasm=yes
make
That's all
The "opt" version is by adding a few additionnal parameters to the compiler.
Overall, even if speed improves over gcc 2.95, it is still slower than icl.
Now, the question is to know if mingw is faster or similar to cygwin.
btw under cygwin you can add -mno-cygwin and the result should be the same than mingw.
./configure --enable-nasm=yes
make
That's all
The "opt" version is by adding a few additionnal parameters to the compiler.
Overall, even if speed improves over gcc 2.95, it is still slower than icl.
Now, the question is to know if mingw is faster or similar to cygwin.
btw under cygwin you can add -mno-cygwin and the result should be the same than mingw.
A little late but here's what I found:
None of the outputted files compared to any other. Note those GCC 3.1 bitrates are way off, just as the DLL's bitrates are also inordinary.
CODE
--aps --aps fast
Mitiok 3:31/182kbps 1:10/183kbps
LAMEDLL(ICL) 3:05/175kbps 1:03/163kbps
GCC 2.95 5:02/182kbps 1:51/183kbps
GCC 3.1 3:28/130kbps 1:45/130kbps
GCC 3.1 Nasm 3:01/130kbps 1:42/130kbps
Mitiok 3:31/182kbps 1:10/183kbps
LAMEDLL(ICL) 3:05/175kbps 1:03/163kbps
GCC 2.95 5:02/182kbps 1:51/183kbps
GCC 3.1 3:28/130kbps 1:45/130kbps
GCC 3.1 Nasm 3:01/130kbps 1:42/130kbps
None of the outputted files compared to any other. Note those GCC 3.1 bitrates are way off, just as the DLL's bitrates are also inordinary.
QUOTE
Originally posted by Destroid
A little late but here's what I found:
None of the outputted files compared to any other. Note those GCC 3.1 bitrates are way off, just as the DLL's bitrates are also inordinary.
A little late but here's what I found:
CODE
--aps --aps fast
Mitiok 3:31/182kbps 1:10/183kbps
LAMEDLL(ICL) 3:05/175kbps 1:03/163kbps
GCC 2.95 5:02/182kbps 1:51/183kbps
GCC 3.1 3:28/130kbps 1:45/130kbps
GCC 3.1 Nasm 3:01/130kbps 1:42/130kbps
Mitiok 3:31/182kbps 1:10/183kbps
LAMEDLL(ICL) 3:05/175kbps 1:03/163kbps
GCC 2.95 5:02/182kbps 1:51/183kbps
GCC 3.1 3:28/130kbps 1:45/130kbps
GCC 3.1 Nasm 3:01/130kbps 1:42/130kbps
None of the outputted files compared to any other. Note those GCC 3.1 bitrates are way off, just as the DLL's bitrates are also inordinary.
It is a bit strange here because on my test music, both GCC3.1 and mitiok's compiles give virtually the same result in alt-preset fast standard. They have the same bitrate and same number of SS and MS frames. And mitiok's compile is just 3 bytes smaller than GCC compile.
Ok, so there is an issue with using GCC3.1 on my non-i686. Maybe that mysterious message was telling me something:
LAME: Can't find termcap entry for terminal "cygwin"
It starts encoding anyway, but seem things were not ok
Of course the nasm-opt compiled crashed right away.
LAME: Can't find termcap entry for terminal "cygwin"
It starts encoding anyway, but seem things were not ok
Of course the nasm-opt compiled crashed right away.
Yep, I get similar results to Destroid:
The first one is my own MinGW32 GCC3.1 compile.
CODE
E:testdir>lame --alt-preset standard 13.wav 13.mp3
LAME version 3.92 MMX ([url]http://www.mp3dev.org/[/url])
CPU features: i387, MMX (ASM used), 3DNow! (ASM used)
Using polyphase lowpass filter, transition band: 18671 Hz - 19205 Hz
Encoding 13.wav to 13.mp3
Encoding as 44.1 kHz VBR(q=2) j-stereo MPEG-1 Layer III (ca. 7.3x) qval=2
Frame | CPU time/estim | REAL time/estim | play/CPU | ETA
8206/8208 (100%)| 1:59/ 1:59| 1:59/ 1:59| 1.7920x| 0:00
32 [ 151] ****
128 [1325] %**************************
160 [3279] %%%%%%%%**********************************************************
192 [2498] %%%%%%%%%%%%%%%************************************
224 [ 565] %%%*********
256 [ 213] %%***
320 [ 177] %***
[B]average: 172.6 kbps LR: 1373 (16.73%) MS: 6835 (83.27%)[/B]
Writing LAME Tag...done
E:testdir>lame-3.1-nasm.exe --alt-preset standard 13.wav 13.mp3
[B]LAME: Can't find termcap entry for terminal "cygwin"[/B]
LAME version 3.92 MMX ([url]http://www.mp3dev.org/[/url])
CPU features: i387, MMX (ASM used), 3DNow! (ASM used)
Using polyphase lowpass filter, transition band: 18671 Hz - 19205 Hz
Encoding 13.wav to 13.mp3
Encoding as 44.1 kHz VBR(q=2) j-stereo MPEG-1 Layer III (ca. 7.3x) qval=2
Frame | CPU time/estim | REAL time/estim | play/CPU | ETA
8206/8208 (100%)| 1:45/ 1:45| 1:45/ 1:45| 2.0365x| 0:00
[B]average: 126.5 kbps LR: 1374 (16.74%) MS: 6834 (83.26%)[/B]
Writing LAME Tag...done
E:testdir>
LAME version 3.92 MMX ([url]http://www.mp3dev.org/[/url])
CPU features: i387, MMX (ASM used), 3DNow! (ASM used)
Using polyphase lowpass filter, transition band: 18671 Hz - 19205 Hz
Encoding 13.wav to 13.mp3
Encoding as 44.1 kHz VBR(q=2) j-stereo MPEG-1 Layer III (ca. 7.3x) qval=2
Frame | CPU time/estim | REAL time/estim | play/CPU | ETA
8206/8208 (100%)| 1:59/ 1:59| 1:59/ 1:59| 1.7920x| 0:00
32 [ 151] ****
128 [1325] %**************************
160 [3279] %%%%%%%%**********************************************************
192 [2498] %%%%%%%%%%%%%%%************************************
224 [ 565] %%%*********
256 [ 213] %%***
320 [ 177] %***
[B]average: 172.6 kbps LR: 1373 (16.73%) MS: 6835 (83.27%)[/B]
Writing LAME Tag...done
E:testdir>lame-3.1-nasm.exe --alt-preset standard 13.wav 13.mp3
[B]LAME: Can't find termcap entry for terminal "cygwin"[/B]
LAME version 3.92 MMX ([url]http://www.mp3dev.org/[/url])
CPU features: i387, MMX (ASM used), 3DNow! (ASM used)
Using polyphase lowpass filter, transition band: 18671 Hz - 19205 Hz
Encoding 13.wav to 13.mp3
Encoding as 44.1 kHz VBR(q=2) j-stereo MPEG-1 Layer III (ca. 7.3x) qval=2
Frame | CPU time/estim | REAL time/estim | play/CPU | ETA
8206/8208 (100%)| 1:45/ 1:45| 1:45/ 1:45| 2.0365x| 0:00
[B]average: 126.5 kbps LR: 1374 (16.74%) MS: 6834 (83.26%)[/B]
Writing LAME Tag...done
E:testdir>
The first one is my own MinGW32 GCC3.1 compile.
QUOTE
LAME: Can't find termcap entry for terminal "cygwin"
I haven't encountered this message myself. Do you know what is the cause?
i did my own ming-compile too (thx to john), and found the same surprises:
with the cygwin i also get the "termcap" message and the histogram isn't displayed.
ming creates the usual screen-output, but both ming and cygwin produce much smaller files in VBR mode.
i tried it with a song by KORN (Metal): --alt-preset fast standard
ming: 128.8 kbps, 2.0874x
cygwin: 138.8 kbps, 2.2813x
ICL45: 190.8 kbps, 3.2093x
the gcc31 compiles sounded horrible...
i guess i'll stick to the good old ICL compiles for the near future.
bye, rocko
with the cygwin i also get the "termcap" message and the histogram isn't displayed.
ming creates the usual screen-output, but both ming and cygwin produce much smaller files in VBR mode.
i tried it with a song by KORN (Metal): --alt-preset fast standard
ming: 128.8 kbps, 2.0874x
cygwin: 138.8 kbps, 2.2813x
ICL45: 190.8 kbps, 3.2093x
the gcc31 compiles sounded horrible...
i guess i'll stick to the good old ICL compiles for the near future.
bye, rocko
i did a little compiling and found that the switch
"-fomit-frame-pointer"
is responsible for the VBR-Bitrate-Breakdown
in the Ming-Compile. It gives correct files (like ICL)
without this switch.
My current minimum-switches are:
-O3 -finline-functions -fexpensive-optimizations
-funroll-loops -ffast-math
Others haven't been tested yet...i doubt that gcc31
will ever reach the speed of icl with LAME.
--alt-preset fast standard:
ming:2.16x
icl45:3.32x
bye,rocko
"-fomit-frame-pointer"
is responsible for the VBR-Bitrate-Breakdown
in the Ming-Compile. It gives correct files (like ICL)
without this switch.
My current minimum-switches are:
-O3 -finline-functions -fexpensive-optimizations
-funroll-loops -ffast-math
Others haven't been tested yet...i doubt that gcc31
will ever reach the speed of icl with LAME.
--alt-preset fast standard:
ming:2.16x
icl45:3.32x
bye,rocko
It's working fine for me with gcc 3.1.1 on Linux, optimizing for athlon-tbird, even with -fomit-frame-pointer. My current switches are:
-O3 -fomit-frame-pointer -ffast-math -funroll-loops -march=athlon-tbird
The -march=athlon-bird provides a 20-25% speed-up over the normal i386 architecture optimization (despite disabling the internal LAME MMX/SSE assembler routines) on my system. I don't have access to ICL or a linux build of ICL-compiled LAME, but my gcc-3.1-linux build now matches (to within about 5%) the speeds I get with mitiok's ICL-win32 build. On an Intel CPU I have no doubt that ICL will still blow gcc-3.1 away, but gcc's athlon optimization is getting very good, whereas ICL has no athlon-specific optimization at all (not surprising, considering what the 'I' in ICL stands for).
-O3 -fomit-frame-pointer -ffast-math -funroll-loops -march=athlon-tbird
The -march=athlon-bird provides a 20-25% speed-up over the normal i386 architecture optimization (despite disabling the internal LAME MMX/SSE assembler routines) on my system. I don't have access to ICL or a linux build of ICL-compiled LAME, but my gcc-3.1-linux build now matches (to within about 5%) the speeds I get with mitiok's ICL-win32 build. On an Intel CPU I have no doubt that ICL will still blow gcc-3.1 away, but gcc's athlon optimization is getting very good, whereas ICL has no athlon-specific optimization at all (not surprising, considering what the 'I' in ICL stands for).
with -march=athlon i get 2.21x-speed.
still not as fast as icl.
could it be a general problem of gcc with windows ?
still not as fast as icl.
could it be a general problem of gcc with windows ?
mmmm.....
on my Athlon650 it was obviously the use of
"-march=i686" and "-fomit-frame-pointer"
at the same time, that caused the VBR Filesize errors.
With "-march=athlon" and "-fomit-frame-pointer"
the filesize is correct now and the speed is gone up to 2.23x
with "--alt-preset fast standard".
i have to be more careful in the future
on my Athlon650 it was obviously the use of
"-march=i686" and "-fomit-frame-pointer"
at the same time, that caused the VBR Filesize errors.
With "-march=athlon" and "-fomit-frame-pointer"
the filesize is correct now and the speed is gone up to 2.23x
with "--alt-preset fast standard".
i have to be more careful in the future
QUOTE
Delerium said...
whereas ICL has no athlon-specific optimization at all (not surprising, considering what the 'I' in ICL stands for).
whereas ICL has no athlon-specific optimization at all (not surprising, considering what the 'I' in ICL stands for).
I'm afraid you are under a misunderstanding here. The 'I' in ICL stands for 'International', as in International Computers Ltd. ICL was the only British manufacturer of mainframe and mini-computers. It is now effectively owned by Fujitsu. I presume that the ICL/Intel compiler situation arises out of a marketing arrangement.
i give up...when i compile with "-march=pentium3" and let it run on my P3-500
i have to leave "-fomit-frame-pointer" away again to get correct files.
mysterious
i have to leave "-fomit-frame-pointer" away again to get correct files.
mysterious
QUOTE
Originally posted by john33
I'm afraid you are under a misunderstanding here. The 'I' in ICL stands for 'International', as in International Computers Ltd. ICL was the only British manufacturer of mainframe and mini-computers. It is now effectively owned by Fujitsu. I presume that the ICL/Intel compiler situation arises out of a marketing arrangement.
I'm afraid you are under a misunderstanding here. The 'I' in ICL stands for 'International', as in International Computers Ltd. ICL was the only British manufacturer of mainframe and mini-computers. It is now effectively owned by Fujitsu. I presume that the ICL/Intel compiler situation arises out of a marketing arrangement.
Everybody calls the Intel C/C++ Compiler (that's the official name) ICL because that's the name of the compiling executable, in oposition to Visual C's CL.EXE.
I stand corrected!!
After reading the GCC-3.1 manpage, it seems that using most of the -f options at all is a bad idea:
I played around with them anyway, and don't notice any measureable speed increase or decrease by playing around with the -f options manually.
QUOTE
-O2 turns on all optional optimizations except for loop unrolling,
function inlining, and register renaming. It also turns on the
-fforce-mem option on all machines and frame pointer elimination on
machines where doing so does not interfere with debugging.
-O3 turns on all optimizations specified by -O2
and also turns on the -finline-functions and -frename-registers
options.
So it would seem then that -O3 turns on all the -f optimizations except -funroll-loops, and -fomit-frame-pointer on architectures where it interferes with debugging. So with the exception of -funroll-loops, it seems like it'd be better to leave off the -f options entirely, and let the -O3 optimization mode handle them intelligently.
function inlining, and register renaming. It also turns on the
-fforce-mem option on all machines and frame pointer elimination on
machines where doing so does not interfere with debugging.
-O3 turns on all optimizations specified by -O2
and also turns on the -finline-functions and -frename-registers
options.
I played around with them anyway, and don't notice any measureable speed increase or decrease by playing around with the -f options manually.
O3 doesn't turn on the math options such as -ffast-math or -fno-trapping-math
I just updated the gcc test binaries. Unfortunately it seems quite slower than icl, but at least I hope it is not crashing anymore.
Please indicate the binary date in reports.
Please indicate the binary date in reports.
Once again another update. I added a 2-pass compilation that should be faster on alt-abr presets
CODE
LAMETEST BINARIES (DATED 08/06/02)
--aps fast --aps 192
lame-icl.exe 1:03 / 182kbps 1:26 / 197kbps
lame-3.1.exe 1:49 / 182kbps 2:09 / 197kbps
lame-3.1-opt.exe 1:50 / 182kbps 2:09 / 197kbps
lame-3.1-opt-2pass.exe 1:43 / 182kbps 2:04 / 197kbps
--aps fast --aps 192
lame-icl.exe 1:03 / 182kbps 1:26 / 197kbps
lame-3.1.exe 1:49 / 182kbps 2:09 / 197kbps
lame-3.1-opt.exe 1:50 / 182kbps 2:09 / 197kbps
lame-3.1-opt-2pass.exe 1:43 / 182kbps 2:04 / 197kbps
File comparisons all ok except for 2-pass ABR. LR/MS of 2-pass ABR was exactly the same as ICL, 3.1 and 3.1-opt.
QUOTE
Originally posted by Gabriel
Once again another update. I added a 2-pass compilation that should be faster on alt-abr presets
Do you have to do anything special to get the 2-pass compilation to work? Using gcc 3.1.1, I compiled with "-march=athlon-tbird -fprofile-arcs" (plus the usual -ffast-math, etc. that's in the standard makefile), then ran lame encoding a file with --alt-preset standard (which correctly generated the various *.da profile files), then tried to recompile with "-march=athlon-tbird -fbranch-probabilities", which got about halfway through and then died with an error about interface.lo.
Once again another update. I added a 2-pass compilation that should be faster on alt-abr presets
Am I missing something?
Nothing special for 2-pass compilation. I just added -fprofile-arcs, compiled, ran (without moving the executable), and recompiled with fprofile-arcs replaced by -fbranch-probabilities.
But I didn't used -march=athlon. I tryed to produce a binary that would work on the same processors as the icl compile. So it works from pentium up to anything more recent. This means that I have -march=i586, even if I added -mcpu=i686
Btw, please also indicate processor when reporting...
One last thing: I had to remove the -fomit-frame-pointer from the switches, as it was breaking alt-presets
But I didn't used -march=athlon. I tryed to produce a binary that would work on the same processors as the icl compile. So it works from pentium up to anything more recent. This means that I have -march=i586, even if I added -mcpu=i686
Btw, please also indicate processor when reporting...
One last thing: I had to remove the -fomit-frame-pointer from the switches, as it was breaking alt-presets
Lametest, binaries from 2002/08/06
Athlon650
-alt preset 192:
lame-3.1: 1.9086x
lame-3.1-opt: 1.9138x
lame-3.1-opt-2pass: 1.9177x
lame-icl: 2.8961x
--alt-preset standard:
lame-3.1: 0.9400x
lame-3.1-opt: 0.9350x
lame-3.1-opt-2pass: 0.9512x
lame-icl: 1.3783x
--alt-preset fast standard:
lame-3.1: 2.2381x
lame-3.1-opt: 2.2398x
lame-3.1-opt-2pass: 2.2064x
lame-icl: 3.2904x
lame without switches:
lame-3.1: 4.2078x
lame-3.1-opt: 4.2431x
lame-3.1-opt-2pass: 4.3123x
lame-icl: 5.7895x
The Bitrates and the LR/MS were the same for all binaries.
The Cygwin exes still give the "termcap" message and don't show the histogram.
Athlon650
-alt preset 192:
lame-3.1: 1.9086x
lame-3.1-opt: 1.9138x
lame-3.1-opt-2pass: 1.9177x
lame-icl: 2.8961x
--alt-preset standard:
lame-3.1: 0.9400x
lame-3.1-opt: 0.9350x
lame-3.1-opt-2pass: 0.9512x
lame-icl: 1.3783x
--alt-preset fast standard:
lame-3.1: 2.2381x
lame-3.1-opt: 2.2398x
lame-3.1-opt-2pass: 2.2064x
lame-icl: 3.2904x
lame without switches:
lame-3.1: 4.2078x
lame-3.1-opt: 4.2431x
lame-3.1-opt-2pass: 4.3123x
lame-icl: 5.7895x
The Bitrates and the LR/MS were the same for all binaries.
The Cygwin exes still give the "termcap" message and don't show the histogram.
Hmmm... I got this error while compiling with MinGW (with gcc 3.1 and binutils 2.12.90) when enabling nasm:
CODE
C:/msys/1.0/mingw/bin/gcc -O3 -fstrength-reduce -fno-expensive-optimizations -finline-functions -fomit-frame-pointer -funroll-loops -ffast-math -foptimize-register-move -fdefer-pop -mcpu=i686 -march=i686 -o C:/msys/1.0/src/lame-3.92/frontend/lame.exe C:/msys/1.0/src/lame-3.92/frontend/main.o C:/msys/1.0/src/lame-3.92/frontend/amiga_mpega.o C:/msys/1.0/src/lame-3.92/frontend/brhist.o C:/msys/1.0/src/lame-3.92/frontend/get_audio.o C:/msys/1.0/src/lame-3.92/frontend/lametime.o C:/msys/1.0/src/lame-3.92/frontend/parse.o C:/msys/1.0/src/lame-3.92/frontend/portableio.o C:/msys/1.0/src/lame-3.92/frontend/timestatus.o
C:/msys/1.0/src/lame-3.92/libmp3lame/libmp3lame.a
C:/msys/1.0/src/lame-3.92/libmp3lame/libmp3lame.a(util.o)(.text+0x2787):util.c: undefined reference to `has_MMX_nasm'
C:/msys/1.0/src/lame-3.92/libmp3lame/libmp3lame.a(util.o)(.text+0x2797):util.c: undefined reference to `has_3DNow_nasm'
C:/msys/1.0/src/lame-3.92/libmp3lame/libmp3lame.a(util.o)(.text+0x27a7):util.c: undefined reference to `has_SIMD_nasm'
C:/msys/1.0/src/lame-3.92/libmp3lame/libmp3lame.a(util.o)(.text+0x27b7):util.c:
undefined reference to `has_SIMD2_nasm'
C:/msys/1.0/src/lame-3.92/libmp3lame/libmp3lame.a(takehiro.o)(.text+0x27ed):takehiro.c: undefined reference to `choose_table_MMX'
C:/msys/1.0/src/lame-3.92/libmp3lame/libmp3lame.a(fft.o)(.text+0x584):fft.c: undefined reference to `fht_3DN'
make: *** [lame.exe] Error 1
C:/msys/1.0/src/lame-3.92/libmp3lame/libmp3lame.a
C:/msys/1.0/src/lame-3.92/libmp3lame/libmp3lame.a(util.o)(.text+0x2787):util.c: undefined reference to `has_MMX_nasm'
C:/msys/1.0/src/lame-3.92/libmp3lame/libmp3lame.a(util.o)(.text+0x2797):util.c: undefined reference to `has_3DNow_nasm'
C:/msys/1.0/src/lame-3.92/libmp3lame/libmp3lame.a(util.o)(.text+0x27a7):util.c: undefined reference to `has_SIMD_nasm'
C:/msys/1.0/src/lame-3.92/libmp3lame/libmp3lame.a(util.o)(.text+0x27b7):util.c:
undefined reference to `has_SIMD2_nasm'
C:/msys/1.0/src/lame-3.92/libmp3lame/libmp3lame.a(takehiro.o)(.text+0x27ed):takehiro.c: undefined reference to `choose_table_MMX'
C:/msys/1.0/src/lame-3.92/libmp3lame/libmp3lame.a(fft.o)(.text+0x584):fft.c: undefined reference to `fht_3DN'
make: *** [lame.exe] Error 1
i'm not sure...but it looks like you didn't include the object files compiled from the
nasm-sources in .libmp3lamei386
nasm-sources in .libmp3lamei386
They are included in libmp3lame.a and even if I include them in the final linking I get these unresolved symbols
Have you included these compile options?
Most of those references come from cpu_feat.nas:
CODE
-DHAVE_NASM -DMMX_choose_table
Most of those references come from cpu_feat.nas:
CODE
globaldef has_MMX_nasm
globaldef has_3DNow_nasm
globaldef has_SIMD_nasm
globaldef has_SIMD2_nasm
globaldef has_3DNow_nasm
globaldef has_SIMD_nasm
globaldef has_SIMD2_nasm
This is a "lo-fi" version of our main content. To view the full version with more information, formatting and images, please click here.