[Gluster-devel] Gluster and GCC 5.1

[Joseph Fernandes]

new patch sent : http://review.gluster.org/#/c/11214/


----- Original Message -----
From: "Niels de Vos" <ndevos at redhat.com>
To: "Prashanth Pai" <ppai at redhat.com>
Cc: "Joseph Fernandes" <josferna at redhat.com>, "Gluster Devel" <gluster-devel at gluster.org>
Sent: Tuesday, June 30, 2015 2:00:15 AM
Subject: Re: [Gluster-devel] Gluster and GCC 5.1

On Mon, Jun 29, 2015 at 01:47:11PM -0400, Prashanth Pai wrote:
> Ah, I thought it was just me who was running into this.
> http://review.gluster.org/11214

Please file a decent bug with the behaviour and error messages. We need
this documented for our users that will likely hit the same problem at
one point.

Thanks,
Niels

> 
> Regards,
>  -Prashanth Pai
> 
> ----- Original Message -----
> > From: "Joseph Fernandes" <josferna at redhat.com>
> > To: "Gluster Devel" <gluster-devel at gluster.org>
> > Sent: Monday, June 29, 2015 5:54:28 PM
> > Subject: [Gluster-devel] Gluster and GCC 5.1
> > 
> > Hi All,
> > 
> > Recently I installed Fedora 22 on some fresh vms, which comes with gcc
> > 5.1.1-1(which can be upgraded to 5.1.1-4)
> > Observed one thing that normal "inline functions" will be undefined symbols
> > in the "so" files.
> > As a result I had trouble in start volume as "gf_sql_str2sync_t"
> > 
> > [2015-06-29 05:52:38.491378] I [MSGID: 101190]
> > [event-epoll.c:627:event_dispatch_epoll_worker] 0-epoll: Started thread with
> > index 1
> > [2015-06-29 05:52:38.499205] W [MSGID: 101095] [xlator.c:189:xlator_dynload]
> > 0-xlator: /usr/local/lib/libgfdb.so.0: undefined symbol: gf_sql_str2sync_t
> > [2015-06-29 05:52:38.499229] E [MSGID: 101002] [graph.y:211:volume_type]
> > 0-parser: Volume 'test-changetimerecorder', line 16: type
> > 'features/changetimerecorder' is not valid or not found on this machine
> > [2015-06-29 05:52:38.499262] E [MSGID: 101019] [graph.y:319:volume_end]
> > 0-parser: "type" not specified for volume test-changetimerecorder
> > [2015-06-29 05:52:38.499335] E [MSGID: 100026]
> > [glusterfsd.c:2151:glusterfs_process_volfp] 0-: failed to construct the
> > graph
> > [2015-06-29 05:52:38.499470] W [glusterfsd.c:1214:cleanup_and_exit] (--> 0-:
> > received signum (0), shutting down
> > 
> > when gf_sql_str2sync_t was made "static inline gf_sql_str2sync_t" the next
> > issue was with "changelog_dispatch_vec"
> > 
> > [2015-06-29 07:11:33.367259] I [MSGID: 101190]
> > [event-epoll.c:627:event_dispatch_epoll_worker] 0-epoll: Started thread with
> > index 1
> > [2015-06-29 07:11:33.368816] W [MSGID: 101095] [xlator.c:189:xlator_dynload]
> > 0-xlator: /usr/local/lib/glusterfs/3.8dev/xlator/features/changelog.so:
> > undefined symbol: changelog_dispatch_vec
> > [2015-06-29 07:11:33.368829] E [MSGID: 101002] [graph.y:211:volume_type]
> > 0-parser: Volume 'test-changelog', line 32: type 'features/changelog' is not
> > valid or not found on this machine
> > [2015-06-29 07:11:33.368843] E [MSGID: 101019] [graph.y:319:volume_end]
> > 0-parser: "type" not specified for volume test-changelog
> > [2015-06-29 07:11:33.368922] E [MSGID: 100026]
> > [glusterfsd.c:2151:glusterfs_process_volfp] 0-: failed to construct the
> > graph
> > [2015-06-29 07:11:33.369025] W [glusterfsd.c:1214:cleanup_and_exit] (--> 0-:
> > received signum (0), shutting down
> > 
> > and so on.
> > 
> > Looks like "inline" functions should be marked as "static inline" or "extern
> > inline" explicitly
> > Please refer https://gcc.gnu.org/gcc-5/porting_to.html
> > 
> > To recreate the issue without glusterfs, try out this sample code program on
> > fedora 22 gcc 5.1.1 or higher
> > 
> > hello.c
> > =======
> > 
> > #include <stdio.h>
> > 
> > inline void foo () {
> >     printf ("hello world");
> > }
> > 
> > int main () {
> > 
> >     foo ();
> >     return 0;
> > }
> > 
> > # gcc hello.c
> > /tmp/ccUQ1XPp.o: In function `main':
> > hello.c:(.text+0xa): undefined reference to `foo'
> > collect2: error: ld returned 1 exit status
> > #
> > 
> > Should we change all the inline function to "static inline" or "extern
> > inline" in gluster, appropriately to their scope of use (IMHO would be a
> > right thing to do)?
> > or should we use a compiler flag to suppress this?
> > 
> > Regards,
> > Joe
> > 
> > 
> > 
> > 
> > _______________________________________________
> > Gluster-devel mailing list
> > Gluster-devel at gluster.org
> > http://www.gluster.org/mailman/listinfo/gluster-devel
> > 
> _______________________________________________
> Gluster-devel mailing list
> Gluster-devel at gluster.org
> http://www.gluster.org/mailman/listinfo/gluster-devel