Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Error compile with NEON enable #487

Open
nintendontit opened this issue Nov 5, 2017 · 2 comments
Open

Error compile with NEON enable #487

nintendontit opened this issue Nov 5, 2017 · 2 comments

Comments

@nintendontit
Copy link

nintendontit commented Nov 5, 2017

CPUFLAGS = -DNO_ASM -DARM -D__arm__ -DARM_ASM -D__NEON_OPT -DNOSSE
CPUFLAGS = -marm -mfloat-abi=hard
HAVE_NEON = 1
WITH_DYNAREC=arm
CPUFLAGS += -mcpu=cortex-a7 -mfpu=neon

This configuration termineted with this error:

./libretro-common/audio/conversion/float_to_s16.o: In function convert_float_to_s16':
float_to_s16.c:(.text+0x8c): undefined reference to convert_float_s16_asm' ./libretro-common/audio/conversion/s16_to_float.o: In function convert_s16_to_float':
s16_to_float.c:(.text+0x8c): undefined reference to convert_s16_float_asm' collect2: error: ld returned 1 exit status Makefile:878: recipe for target 'parallel_n64_libretro.so' failed make: *** [parallel_n64_libretro.so] Error 1

If remove HAVE_NEON = 1 and -mfpu=neon compilation and without issue

My CPU have neon support:
CPU: swp half thumb fastmult vfp edsp thumbee neon vfpv3 tls vfpv4 idiva idivt

What's problem on compiling with neon enable?
GCC is 4.9.2, os is Debian

@zanac
Copy link

zanac commented Dec 15, 2017

I confirm the issue with neon it cannot find convert_float_s16_asm!

As workaround for now to compile it i just replaced the ifdef ARM_NEON in s16_to_float.c with a DUMMY_NEON so it compile fine but instead of use native asm it will fallback with C code.

@metamorphling
Copy link

metamorphling commented Dec 20, 2017

| LD retroarch
| obj-unix/audio/drivers_resampler/cc_resampler.o: In function `resampler_CC_upsample':
| /usr/src/debug/retroarch/1.0-r0/git/audio/drivers_resampler/cc_resampler.c:368: undefined reference to `resampler_CC_upsample_neon'
| obj-unix/audio/drivers_resampler/cc_resampler.o: In function `resampler_CC_downsample':
| /usr/src/debug/retroarch/1.0-r0/git/audio/drivers_resampler/cc_resampler.c:362: undefined reference to `resampler_CC_downsample_neon'
| obj-unix/./libretro-common/audio/conversion/s16_to_float.o: In function `convert_s16_to_float':
| /usr/src/debug/retroarch/1.0-r0/git/libretro-common/audio/conversion/s16_to_float.c:107: undefined reference to `convert_s16_float_asm'
| obj-unix/./libretro-common/audio/conversion/float_to_s16.o: In function `convert_float_to_s16':
| /usr/src/debug/retroarch/1.0-r0/git/libretro-common/audio/conversion/float_to_s16.c:99: undefined reference to `convert_float_s16_asm'
| collect2: error: ld returned 1 exit statu

Tried to compile with arm-none-linux-gnueabi-gcc -march=armv7ve -marm -mfpu=neon -mfloat-abi=hard -mcpu=cortex-a7, at linking step seing some cross-compilation problems too. Will poke it a little bit when I have time.

UPDATE:
Wow, managed to build it. I see there is no work done for abstract linux boards, for example setting sysroot did nothing good for library paths. That said, I was trying to build it by Yocto for custom imx6 board.
Being on the topic, for me HAVE_NEON never went to 1, and that was the reason why linking to assembler files failed.
I can see that HAVE_NEON is getting set only in configs of specific platforms, so that should stay as is. At the same time, it would be cool to introduce logic for configure step like:

  1. check if platform specified
  2. if not, determine compiler provided in $CC
  3. try to parse as much data as possible to understand what defines should be flipped

For example, HAVE_NEON check

arm-none-linux-gnueabi-gcc -march=armv7ve -marm -mfpu=neon -mfloat-abi=hard -mcpu=cortex-a7 -dM -E - < /dev/null | grep NEON
#define __ARM_NEON_FP 4
#define __ARM_NEON__ 1
#define __ARM_NEON 1

Preprocessor definitions dump is easily obtainable data, at least for gcc. That is why 2nd step is important, to determine which compiler in use.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants