Bug 1782054 - Linking fails with undefined symbol error "basename_r"
Summary: Linking fails with undefined symbol error "basename_r"
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: GlusterFS
Classification: Community
Component: build
Version: 7
Hardware: x86_64
OS: FreeBSD
medium
medium
Target Milestone: ---
Assignee: Shwetha K Acharya
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2019-12-11 04:29 UTC by Daniel Morante
Modified: 2020-07-12 06:51 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2019-12-12 05:47:08 UTC
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Embargoed:


Attachments (Terms of Use)
Patch to fix build on FreeBSD (1.03 KB, patch)
2020-07-12 06:51 UTC, Daniel Morante
no flags Details | Diff

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


Note You need to log in before you can comment on or make changes to this bug.