undefined reference to `access' using devkitPPC r29-1

[nebiun]

Found the problem trying to compile libpng-1.6.28 (portlibs)

issue opened at
https://github.com/devkitPro/newlib/issues/4

Error compiling libpng-1.6.28 (portlibs)

Code: Select all

Makefile generated with this script:

---cut here
#!/bin/bash

PATH=${DEVKITPPC}/bin:${PATH}
HOST=powerpc-eabi
PREFIX=${DEVKITPRO}/portlibs/ppc

#libpng
cd libpng*
CPPFLAGS=-I${PREFIX}/include LDFLAGS=-L${PREFIX}/lib ./configure 
--prefix=${PREFIX} --host=${HOST} --disable-shared --enable-static
make && make install
cd ${home}

---cut here

This is the output:

Code: Select all

$ make
make all-am
make[1]: Entering directory /c/Users/Nebiun/Downloads/WIIdev/portlibs_2017/libp ng-1.6.28' /bin/sh ./libtool --tag=CC --mode=link powerpc-eabi-gcc -g -O2 -L/c/devkitP ro/portlibs/ppc/lib -o pngcp contrib/tools/pngcp.o libpng16.la -lz -lm libtool: link: powerpc-eabi-gcc -g -O2 -o pngcp contrib/tools/pngcp.o -L/c/devk itPro/portlibs/ppc/lib ./.libs/libpng16.a -lz -lm c:/devkitpro/devkitppc/bin/../lib/gcc/powerpc-eabi/6.3.0/../../../../powerpc-eab i/bin/ld.exe: warning: cannot find entry symbol _start; defaulting to 018000b8 contrib/tools/pngcp.o: In functionisdir':
c:\Users\Nebiun\Downloads\WIIdev\portlibs_2017\libpng-1.6.28/contrib/tools/pngcp
.c:1610: undefined reference to access' contrib/tools/pngcp.o: In functioncp_one_file':
c:\Users\Nebiun\Downloads\WIIdev\portlibs_2017\libpng-1.6.28/contrib/tools/pngcp
.c:2176: undefined reference to access' c:\Users\Nebiun\Downloads\WIIdev\portlibs_2017\libpng-1.6.28/contrib/tools/pngcp .c:2207: undefined reference toaccess'
collect2.exe: error: ld returned 1 exit status
make[1]: *** [pngcp] Error 1
make[1]: Leaving directory `/c/Users/Nebiun/Downloads/WIIdev/portlibs_2017/libpn
g-1.6.28'
make: *** [all] Error 2

[nebiun]

Same problem with devkitPPC r28

[nebiun]

And in devkitPPC r27.

access prototype and defines needed for call the function are present in

devkitPPC/powerpc-eabi/include/sys/unistd.h

but the function is not in the library

[Oibaf]

You can use this function to replace the "acccess function":

Code: Select all

 
static int wii_access (const char *pathname, int mode)
{
	struct stat st;

	if (stat(pathname, &st) < 0)
		return -1;
		
	return 0; //With Wii the file/dir is considered always accessible if it exists
}
#define access wii_access

[nebiun]

You can use this function to replace the "acccess function":

Code: Select all

 
static int wii_access (const char *pathname, int mode)
{
	struct stat st;

	if (stat(pathname, &st) < 0)
		return -1;
		
	return 0; //With Wii the file/dir is considered always accessible if it exists
}
#define access wii_access

Problem is not emulate the function. Problem is add it to the standard library to avoid the need to add it to all packages that require access

[WinterMute]

The access error is coming from attempting to build tools for the host platform which makes no sense for our use case. The simplest way to get latest libpng built for devkitARM or devkitPPC is to patch out the tool binaries & tests which require this function. I would probably do this anyway even if the link error was fixed since the binaries serve no purpose with a bare metal toolchain.

You can grab a patched libpng 1.6.28 from https://sourceforge.net/projects/devkit ... tlibs/src/

[nebiun]

The access error is coming from attempting to build tools for the host platform which makes no sense for our use case. The simplest way to get latest libpng built for devkitARM or devkitPPC is to patch out the tool binaries & tests which require this function. I would probably do this anyway even if the link error was fixed since the binaries serve no purpose with a bare metal toolchain.

You can grab a patched libpng 1.6.28 from https://sourceforge.net/projects/devkit ... tlibs/src/

I don't know where is the problem to add "access" to newlib, when with a very little work we can have a working version of it.
"access" is a unix and linux syscall and it is used in many source. The needed defines and the prototype are already in devkitPPC/powerpc-eabi/include/sys/unistd.h.
Really is best modify the sources every time you update a portlibs?
If a library does not work, I must modify the original source, but if the problem is a missing routine that I can simply wrap, then I prefer wrap it and leave the original source untouched.

[WinterMute]

The problem here isn't that the library won't compile but that the associated tools and tests won't compile. These tools and tests are useless for bare metal so these have been patched out of the build process.

Even if they compiled they would still serve no purpose for a bare metal cross compiler - you can't run them. If you need the tools then they need compiled for the system you're compiling on NOT the system you're compiling for.

[nebiun]

The problem here isn't that the library won't compile but that the associated tools and tests won't compile. These tools and tests are useless for bare metal so these have been patched out of the build process.

Even if they compiled they would still serve no purpose for a bare metal cross compiler - you can't run them. If you need the tools then they need compiled for the system you're compiling on NOT the system you're compiling for.

The problem is not related to the compilation of libpng or a test process or a particular source.
I think that newlib library should have the "access" routine inside, because it is present in the standard u*x library (POSIX.1-2001).

[WinterMute]

But you reported that libpng wouldn't compile showing an error that comes from attempting to build executables which serve no purpose in this environment. The library itself does not require an access implementation and the binaries which do should not be built.

That's not to say that access should not be implemented it's just that the correct solution for the issue you reported is to patch the libpng build process to prevent building of problematic executables. Those binaries will be compiled to run on bare-metal powerpc-eabi but will be installed on your build system where they cannot be executed and may cause problems.