Bug 1782054

Summary: Linking fails with undefined symbol error "basename_r"
Product: [Community] GlusterFS Reporter: Daniel Morante <daniel>
Component: buildAssignee: Shwetha K Acharya <sacharya>
Status: CLOSED WONTFIX QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: 7CC: bugs, sabose, sacharya
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: FreeBSD   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2019-12-12 05:47:08 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
Patch to fix build on FreeBSD none

Description Daniel Morante 2019-12-11 04:29:39 UTC 
Description of problem:

On FreeBSD 12.1-RELEASE GlusterFS 7.0 appears to build correctly but fails on the linking step with: "ld: error: undefined symbol: basename_r"

Version-Release number of selected component (if applicable): 7.0

How reproducible: Always

Steps to Reproduce:

1. Use the existing port skeleton for version 3.11.1
2. update the patch files (line number changes, same patches still work)
3. re-configure the dependencies for 7.0. 

Actual results:

Build succeeds, linking fails.


Expected results:

Linking should succeed.


Additional info:

Relevant output from console:

```
...
--- all-recursive ---
Making all in src
Making all in glusterfsd
--- all-recursive ---
Making all in src
--- glusterfsd ---
/bin/sh ../../libtool  --tag=CC    --mode=link cc -Wall -I/usr/local/include/uuid -I/usr/local/include  -Wformat -Werror=format-security -Werror=implicit-function-declaration -Wno-gnu -O0 -DTHREAD_UNSAFE_BASENAME -DTHREAD_UNSAFE_DIRNAME -D_LIBGEN_H_ -DO_DSYNC=0 -Dxdr_quad_t=xdr_longlong_t -Dxdr_u_quad_t=xdr_u_longlong_t -O2 -pipe  -fstack-protector-strong -fno-strict-aliasing  -isystem /usr/local/include  -rdynamic -lexecinfo -ldl -L/usr/local/lib -largp -L/usr/local/lib  -fstack-protector-strong -o glusterfsd glusterfsd.o glusterfsd-mgmt.o ../../libglusterfs/src/libglusterfs.la  ../../rpc/rpc-lib/src/libgfrpc.la  ../../rpc/xdr/src/libgfxdr.la -largp -lm -lrt -lintl -lpthread -lcrypto
libtool: link: cc -Wall -I/usr/local/include/uuid -I/usr/local/include -Wformat -Werror=format-security -Werror=implicit-function-declaration -Wno-gnu -O0 -DTHREAD_UNSAFE_BASENAME -DTHREAD_UNSAFE_DIRNAME -D_LIBGEN_H_ -DO_DSYNC=0 -Dxdr_quad_t=xdr_longlong_t -Dxdr_u_quad_t=xdr_u_longlong_t -O2 -pipe -fstack-protector-strong -fno-strict-aliasing -isystem /usr/local/include -rdynamic -fstack-protector-strong -o .libs/glusterfsd glusterfsd.o glusterfsd-mgmt.o  -ldl -L/usr/local/lib ../../libglusterfs/src/.libs/libglusterfs.so ../../rpc/rpc-lib/src/.libs/libgfrpc.so /usr/ports/net/glusterfs7/work/glusterfs-7.0/rpc/xdr/src/.libs/libgfxdr.so ../../rpc/xdr/src/.libs/libgfxdr.so /usr/ports/net/glusterfs7/work/glusterfs-7.0/libglusterfs/src/.libs/libglusterfs.so -lexecinfo -largp -lz -lm -luuid -lrt -lintl -lpthread -lcrypto -Wl,-rpath -Wl,/usr/local/lib
ld: error: undefined symbol: basename_r
>>> referenced by glusterfsd.c
>>>               glusterfsd.o:(parse_cmdline)

ld: error: undefined symbol: basename_r
>>> referenced by glusterfsd.c
>>>               glusterfsd.o:(parse_cmdline)
cc: error: linker command failed with exit code 1 (use -v to see invocation)
*** [glusterfsd] Error code 1
```
Comment 1 Sahina Bose 2019-12-11 07:24:19 UTC 
Shwetha, can you take a look. Or reassign to someone looking at build?
Comment 2 Shwetha K Acharya 2019-12-12 05:47:08 UTC 
Sahina, 
We have stopped supporting freebsd. Hence I am closing this bug.
Comment 3 Daniel Morante 2020-07-12 06:51:57 UTC 
Created attachment 1700713 [details]
Patch to fix build on FreeBSD

The solution for this was simple and just needed a tiny change to configure.ac.  I've attached the patch for version 7.6 release.

I also see that the master branch of GlusterFS has a similar version of this fix applied.  However, my patch continues to support FreeBSD 12.0 and 11.3