In D8263#171941, @mat wrote:

I guess this is so that there can be many u-boot-* ports that all do the same thing ?
In that case, I really thing the way to go is not a USES but a master port, with slaves only changing the MODEL/BOARD_CONFIG/...

Also this is not the correct fix. I'll have a look at py-numpy later. Uses/fortran.mk is not the file to modify here.

patch<

• fortran.mk.orig 2015-09-16 00:20:24.419637000 -0400

+++ fortran.mk 2015-09-23 17:31:19.740665000 -0400
@@ -29,8 +29,8 @@
F77= gfortran${_GCC_VER}
FC= gfortran${_GCC_VER}
FFLAGS+= -Wl,-rpath=${LOCALBASE}/lib/gcc${_GCC_VER}
-FCFLAGS+= -Wl,-rpath=${LOCALBASE}/lib/gcc${_GCC_VER}
-LDFLAGS+= -Wl,-rpath=${LOCALBASE}/lib/gcc${_GCC_VER} \
+#FCFLAGS+= -Wl,-rpath=${LOCALBASE}/lib/gcc${_GCC_VER}
+#LDFLAGS+= -Wl,-rpath=${LOCALBASE}/lib/gcc${_GCC_VER} \

-L${LOCALBASE}/lib/gcc${_GCC_VER} -B${LOCALBASE}/bin

.elif ${fortran_ARGS} == ifort
BUILD_DEPENDS+= ${LOCALBASE}/intel_fc_80/bin/ifort:${PORTSDIR}/lang/ifc

What happens if you compile with USE_GCC removed? Does gnuradio-companion run for you?

Try (assuming you are using sh or zsh etc.)
export LD_PRELOAD=/usr/local/lib/gcc48/libgcc_s.so
gnuradio-companion

What happens if you compile with USE_GCC removed? Does gnuradio-companion run for you?

Looks like I had private email exchanges about this back in June

In D3574#73712, @rakuco wrote:

Right, the situation you've summed up is basically bug 196491 as far as I can see.

I don't use GNU Radio myself, so I'm sorry if the questions I ask sound stupid:

• Would it help if Volk was built separately from the rest of GNU Radio, so the former links against clang and the latter against GCC? Debian ships Volk separately, for example, and builds GNU Radio with -DENABLE_INTERNAL_VOLK=OFF.
• How about disabling Volk support? I see that it is at least possible from a build system perspective, but I'm not sure if other functionality will also be disabled, or if it is too important to be disabled.

The problem gets *very* stupid here. It's not this easy.

Indeed it's not directly related but I wanted it noted. Shall I file a PR on py-scipy then?
Meanwhile py-numpy looks good.

py-numpy installs fine but there is now a conflict on a dependancy

Right. It's something that should be noted and documented perhaps in the porters handbook.

Correction NUMPY consumers which also use Fortran.

One concern is consumers reliant on f2py will have to be chased up.

One of the best loggers going. Commit please.

I'd double check the configure.ac script here before sending fix upstream.
e.g. configure was modified to look for std::hash etc. to make it non specific to GCC or Clang since one of my earlier diffs I sent upstream was too specific.

Approved on this end. skreuzer?

Looks good to me. skreuzer?

Nice I approve subject to skreuzer approval as well.

The only major comment I'd make is there are two other smith chart programs in /science not /comms also maintained by hamradio perhaps this one should fall into science hamradio as do gsmc and tinsmith

Nice job.
FWIW I was never happy with this stanza I added to the Makefile

Approved.

Looks good here. Fair bit of work on this one eh?

Looks good! commit!

Looks good to me.

I do believe the .if ${PORT_OPTIONS:MDOCS} is entirely unnecessary with staging.

Are you mirroring it or are you going to ask me to mirror it? If you are mirroring it, change
MASTER_SITE_SUBDIR= shurd ;)
put a copy of the tar ball in your public_distfiles