Something really funky is happening on your system.

A normal thing like:
/bin/sh ../../libtool  --tag=CC   --mode=link gcc48  -O2 -pipe $(includes) $(warings) $(compiler_f_flags) $(some_rpaths) -o libloader.la  $(some).lo

Results in:
libtool: link: gcc48 -shared  -fPIC -DPIC  ... -Wl,-soname -Wl,libloader.so.0 -o .libs/libloader.so.0.0.0

In the above - -shared and -Wl,-soname should be missing. With the output filename being libloader.la

Same applies for other static libraries.

A few things to try:
 - remove and/or build w/o LLVM
 - try a simple project which builds a bunch of static libs and links them into a shared one
 - what is the latest supported Mesa on FreeBSD 9.3, does it build OK?
 - does the latest supported FreeBSD build fine?

Same thing happens without LLVM (first thing I did was strip it all back to the bare minimum.)

This is the only one out of 1200 that fails, so there is something specific to do with the setup of this one.

If I build with GCC 4.2 it works, but not GCC 4.8.5 and I have no clue about FreeBSD 10/11 as I don't use either at the moment, but one would assume they do work.  They are also built with clang and not GCC.

Will look for the -shared flag to see where it is being added, though I am a little surprised that it would fail to link based on shared or not.

It would appear that the -shared flag is being added by configure...

    # FreeBSD 3 and greater uses gcc -shared to do shared libraries.
    freebsd* | dragonfly*)
      archive_cmds='$CC -shared $pic_flag -o $lib $libobjs $deplibs $compiler_flags'
      hardcode_libdir_flag_spec='-R$libdir'
      hardcode_direct=yes
      hardcode_shlibpath_var=no
      ;;

(around line 12723)

After pulling back even more (basically issuing a 'mv configure.orig configure' before running configure) I noticed this...

/bin/sh ../../libtool  --tag=CC   --mode=link gcc48 -I../../include -I../../src/loader -I../../src/gbm/main  -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -DUSE_SSE41 -DUSE_GCC_ATOMIC_BUILTINS -DNDEBUG -DUSE_X86_64_ASM -DHAVE_XLOCALE_H -DHAVE_SYS_SYSCTL_H -DHAVE_STRTOF -DHAVE_DLOPEN -DHAVE_DL_ITERATE_PHDR -DHAVE_POSIX_MEMALIGN -DHAVE_LIBDRM -DGLX_USE_DRM -DGLX_INDIRECT_RENDERING -DGLX_DIRECT_RENDERING -DENABLE_SHADER_CACHE -DHAVE_MINCORE -DHAVE_LLVM=0x0400 -DMESA_LLVM_VERSION_PATCH=1 -fvisibility=hidden  -DDEFAULT_DRIVER_DIR='"/usr/local/lib/dri"' -I/usr/local/include -I/usr/local/include/libdrm   -pthread   -O2 -pipe -isystem /usr/local/include -fstack-protector -Wl,-rpath=/usr/local/lib/gcc48 -fno-strict-aliasing -Wall -std=c99 -Werror=implicit-function-declaration -Werror=missing-prototypes -fno-math-errno -fno-trapping-math  -no-undefined -version-info 1:0 -Wl,--gc-sections -Wl,--no-undefined -L/usr/local/lib -Wl,-rpath=/usr/local/llvm40/lib -fstack-protector -rpath /usr/local/lib/gcc48 -L/usr/local/lib/gcc48 -o libgbm.la -rpath /usr/local/lib main/backend.lo main/gbm.lo backends/dri/gbm_dri.lo ../../src/loader/libloader.la   -L/usr/local/lib -ldrm   -pthread 

Which shows that libloader.la is being created.. the next line was to create a shared lib for libloader.. the key to the problem being when it comes to linking that to libgbm... the line before:

libtool: warning: ignoring multiple '-rpath's for a libtool library

Followed by:
libtool: link: gcc48 -shared  -fPIC -DPIC  main/.libs/backend.o main/.libs/gbm.o backends/dri/.libs/gbm_dri.o   -Wl,-rpath -Wl,/wrkdirs/usr/ports/graphics/mesa-libs/work/mesa-17.1.0/src/loader/.libs -Wl,-rpath -Wl,/wrkdirs/usr/ports/graphics/mesa-libs/work/mesa-17.1.0/src/mesa/drivers/dri/common/.libs -Wl,-rpath -Wl,/usr/local/lib/gcc48 -L/wrkdirs/usr/ports/graphics/mesa-libs/work/mesa-17.1.0/src/mesa/drivers/dri/common/.libs -L/usr/local/lib -L/usr/local/lib/gcc48 ../../src/loader/.libs/libloader.so /wrkdirs/usr/ports/graphics/mesa-libs/work/mesa-17.1.0/src/mesa/drivers/dri/common/.libs/libxmlconfig.so -lexpat -lm -ldrm  -pthread -O2 -fstack-protector -Wl,-rpath=/usr/local/lib/gcc48 -Wl,--gc-sections -Wl,--no-undefined -Wl,-rpath=/usr/local/llvm40/lib -fstack-protector -pthread   -pthread -Wl,-soname -Wl,libgbm.so.1 -o .libs/libgbm.so.1.0.0

The problem is the 2 'rpath's brought about by the following make environmental var:

LDFLAGS=-rpath ${_GCC_RUNTIME} -L${_GCC_RUNTIME}

...the build env has the following:

CC:=                    gcc${V}
CXX:=                   g++${V}
CPP:=                   cpp${V}
_GCC_RUNTIME:=          ${LOCALBASE}/lib/gcc${V}
CFLAGS+=                -Wl,-rpath=${_GCC_RUNTIME}
CXXFLAGS+=              -Wl,-rpath=${_GCC_RUNTIME}
LDFLAGS+=              -rpath ${_GCC_RUNTIME} -L${_GCC_RUNTIME}

Commenting out the LDFLAGS rpath additional variable fixes it.

Reverting all the other changes to see if it still builds.. if it does reverting back to 17.2.x and see if that builds...

Regards,

Michelle

All working after reverting all the changes - moving on to test against 17.3, but am fairly confident it'll be fine.  So consider closed.

Confirmed: 17.3 works fine with that ENV change.