Page 1 of 1

devkitPPC release 34

Posted: Mon Feb 11, 2019 9:46 pm
by WinterMute
devkitPPC release 34 is now available via pacman. Use sudo (dkp-)pacman -Syu to update or sudo (dkp-)pacman -S devkitPPC to install.

devkitPPC release 34
  • fix struct timeval issue properly
  • update to binutils 2.32
  • remove old -mwup options in favour of external linkscripts & support for libwut
  • remove rules files in favour of separate devkitppc-rules package for easier updates.

Re: devkitPPC release 34

Posted: Tue Feb 12, 2019 9:41 pm
by nebiun
And old makefiles now does not work because you are changed PORTLIBS value... :(
From:
/opt/devkitpro/portlibs/ppc
to:
/opt/devkitpro/portlibs/wii /opt/devkitpro/portlibs/ppc

Code: Select all

#---------------------------------------------------------------------------------
# build a list of include paths
#---------------------------------------------------------------------------------
export INCLUDE	:=	$(foreach dir,$(INCLUDES), -iquote $(CURDIR)/$(dir)) \
					$(foreach dir,$(LIBDIRS),-I$(dir)/include) \
					-I$(CURDIR)/include \
					-I$(PORTLIBS)/include \
					-I$(LIBOGC_INC)

#---------------------------------------------------------------------------------
# build a list of library paths
#---------------------------------------------------------------------------------
export LIBPATHS	:=	$(foreach dir,$(LIBDIRS),-L$(dir)/lib) \
					-L$(PORTLIBS)/lib -L$(LIBOGC_LIB)

Re: devkitPPC release 34

Posted: Tue Feb 12, 2019 10:03 pm
by nebiun
This is the modified version of previous Makefile

Code: Select all

#---------------------------------------------------------------------------------
# build a list of include paths
#---------------------------------------------------------------------------------
export INCLUDE	:=	$(foreach dir,$(INCLUDES), -iquote $(CURDIR)/$(dir)) \
					$(foreach dir,$(LIBDIRS),-I$(dir)/include) \
					-I$(CURDIR)/include \
					$(foreach dir,$(PORTLIBS),-I$(dir)/include) \
					-I$(LIBOGC_INC)

#---------------------------------------------------------------------------------
# build a list of library paths
#---------------------------------------------------------------------------------
export LIBPATHS	:=	$(foreach dir,$(LIBDIRS),-L$(dir)/lib) \
					$(foreach dir,$(PORTLIBS),-L$(dir)/lib) \
					-L$(LIBOGC_LIB)

Re: devkitPPC release 34

Posted: Wed Feb 13, 2019 9:29 am
by WinterMute
Where did you get that from? That's not how you're supposed to use PORTLIBS.

https://github.com/devkitPro/wii-exampl ... kefile#L42

Code: Select all

#---------------------------------------------------------------------------------
# list of directories containing libraries, this must be the top level containing
# include and lib
#---------------------------------------------------------------------------------
LIBDIRS	:= $(PORTLIBS)

Re: devkitPPC release 34

Posted: Wed Feb 13, 2019 2:25 pm
by nebiun
WinterMute wrote:
Wed Feb 13, 2019 9:29 am
Where did you get that from? That's not how you're supposed to use PORTLIBS.
:oops:
I will change all my Makefile...

Question:
/opt/devkitpro/portlibs/wii
is a new directory for users libs and include?

Re: devkitPPC release 34

Posted: Wed Feb 13, 2019 9:05 pm
by WinterMute
nebiun wrote:
Wed Feb 13, 2019 2:25 pm

Question:
/opt/devkitpro/portlibs/wii
is a new directory for users libs and include?
No. There should be nothing installed inside the devkitpro folder that hasn't been released by devkitPro.

Re: devkitPPC release 34

Posted: Wed Feb 13, 2019 9:38 pm
by nebiun
WinterMute wrote:
Wed Feb 13, 2019 9:05 pm
nebiun wrote:
Wed Feb 13, 2019 2:25 pm

Question:
/opt/devkitpro/portlibs/wii
is a new directory for users libs and include?
No. There should be nothing installed inside the devkitpro folder that hasn't been released by devkitPro.
Really?
But where I can put libraries like libwiisprite, libml, libgrr and other libraries like these?
Why not in /opt/devkitpro/userlibs or similar?

Re: devkitPPC release 34

Posted: Thu Feb 14, 2019 12:32 am
by WinterMute
Having libraries inside the devkitpro folder implies that they're endorsed and/or recommended by us which, unless they're provided by our pacman, they're not.

We don't want to endorse libraries that do crazy things like use the GPU to plot pixels in order to draw text. We don't want to endorse libraries that use individual png files converted at runtime for each graphic used. These are just incredibly bad ways to manage resources and we'd like to discourage these practices.