[MacPorts] #40531: codeblocks: universal variant fails when non-universal codeblocks is already installed

[MacPorts]

#40531: codeblocks: universal variant fails when non-universal codeblocks is
already installed
---------------------------+---------------------
  Reporter:  ryandesign@…  |      Owner:  mojca@…
      Type:  defect        |     Status:  new
  Priority:  Normal        |  Milestone:
 Component:  ports         |    Version:  2.2.0
Resolution:                |   Keywords:
      Port:  codeblocks    |
---------------------------+---------------------

Comment (by mojca@…):

 As Rainer Müller pointed it out on IRC, the `Makefile` first generates
 {{{
 /bin/sh ../../libtool --tag=CXX   --mode=link ccache /usr/bin/clang++  -O2
 -ffast-math -DCB_AUTOCONF -pipe -Os -arch x86_64 -arch i386
 -stdlib=libstdc++  -fPIC -DPIC -fexceptions  -L/opt/local/lib
 -Wl,-headerpad_max_install_names -arch x86_64 -arch i386 -o codeblocks
 app.o [...] watchesdlg.o -L../sdk -lcodeblocks [...]
 }}}
 but `libtool` turns that into
 {{{
 libtool: link: ccache /usr/bin/clang++ -O2 -ffast-math -DCB_AUTOCONF -pipe
 -Os -arch x86_64 -arch i386 -stdlib=libstdc++ -fPIC -DPIC -fexceptions
 -Wl,-headerpad_max_install_names -arch x86_64 -arch i386 -o codeblocks
 app.o [...] watchesdlg.o -Wl,-headerpad_max_install_names
 -L/opt/local/lib -L../sdk /opt/local/lib/libcodeblocks.dylib [...]
 }}}

 The problem is that
 {{{
 -L/opt/local/lib -L../sdk -lcodeblocks
 }}}
 will would link against the wrong library in either case (even if
 `libtool` didn't replace the link). Based on his advice I created a patch
 that replaces
 {{{
 -L../sdk -lcodeblocks
 }}}
 with
 {{{
 ../sdk/.libs/libcodeblocks.dylib
 }}}
 in the original `Makefile`, hoping that this would solve the problem.

 I'm not sure about a sane way to fix this upstream.

-- 
Ticket URL: <https://trac.macports.org/ticket/40531#comment:4>
MacPorts <http://www.macports.org/>
Ports system for OS X