ruby: building with CFLAGS="something"

ruby: building with CFLAGS="something"

[David Bremner]

The rest of the (C and C++) codebase supports

    make CFLAGS="-g -O0"

or

    CFLAGS="-g -O0" ./configure
    
but the ruby bindings don't build:

    linking shared-object notmuch.so
    /usr/bin/ld: status.o: warning: relocation against `notmuch_rb_eUnbalancedAtomicError' in read-only section `.text'
    /usr/bin/ld: database.o: relocation R_X86_64_PC32 against symbol `ID_db_create' can not be used when making a shared object; recompile with -fPIC
    /usr/bin/ld: final link failed: bad value
    collect2: error: ld returned 1 exit status
    make[1]: *** [Makefile:262: notmuch.so] Error 1
    make[1]: Leaving directory '/home/bremner/software/upstream/notmuch/bindings/ruby'
    make: *** [bindings/Makefile.local:9: ruby-bindings] Error 2

It would be nice if bindings/ruby/Makefile could be made to confirm to
the notmuch conventions, but since it's autogenerated I don't know how
realistic that is.  Failing that we could think about adjusting the
notmuch build system, ideally conforming to some standard-ish
behaviour.

I guess a hack that might work is to unset the corresponding variables
in the shim bindings/Makefile.local; something like the following, but
more portable

diff --git a/bindings/Makefile.local b/bindings/Makefile.local
index bc960bbc..8e3cd051 100644
--- a/bindings/Makefile.local
+++ b/bindings/Makefile.local
@@ -10,7 +10,7 @@ ifeq ($(HAVE_RUBY_DEV),1)
                LIBNOTMUCH="../../lib/$(LINKER_NAME)" \
                NOTMUCH_SRCDIR='$(NOTMUCH_SRCDIR)' \
                $(RUBY) extconf.rb --vendor
-       $(MAKE) -C $(dir)/ruby
+       env -u CFLAGS $(MAKE) -C $(dir)/ruby
 endif

Re: ruby: building with CFLAGS="something"

[Felipe Contreras]

On Sun, May 16, 2021 at 7:28 AM David Bremner <david@tethera.net> wrote:
>
>
> The rest of the (C and C++) codebase supports
>
>     make CFLAGS="-g -O0"
>
> or
>
>     CFLAGS="-g -O0" ./configure
>
> but the ruby bindings don't build:

That's because -fPIC is needed.

The way Ruby's mkmf generates the Makefile is wrong, because it should do:

  override CFLAGS+=-fPIC

So that the user can specify other CFLAGS.

However, we can fix that by doing that ourselves:

--- a/bindings/Makefile.local
+++ b/bindings/Makefile.local
@@ -10,7 +10,7 @@ ifeq ($(HAVE_RUBY_DEV),1)
                LIBNOTMUCH="../../lib/$(LINKER_NAME)" \
                NOTMUCH_SRCDIR='$(NOTMUCH_SRCDIR)' \
                $(RUBY) extconf.rb --vendor
-       $(MAKE) -C $(dir)/ruby
+       $(MAKE) -C $(dir)/ruby CFLAGS="$(CFLAGS) -pipe -fno-plt -fPIC"
 endif

We lose -march=x86-64 -mtune=generic (at least on my machine), but I
guess that's not a big deal since libnotmuch itself isn't getting
compiled with those.

I'll send a patch soonish.

-- 
Felipe Contreras

Re: ruby: building with CFLAGS="something"

[Tomi Ollila]

On Sun, May 16 2021, Felipe Contreras wrote:

> On Sun, May 16, 2021 at 7:28 AM David Bremner <david@tethera.net> wrote:
>>
>>
>> The rest of the (C and C++) codebase supports
>>
>>     make CFLAGS="-g -O0"
>>
>> or
>>
>>     CFLAGS="-g -O0" ./configure
>>
>> but the ruby bindings don't build:
>
> That's because -fPIC is needed.
>
> The way Ruby's mkmf generates the Makefile is wrong, because it should do:
>
>   override CFLAGS+=-fPIC
>
> So that the user can specify other CFLAGS.
>
> However, we can fix that by doing that ourselves:
>
> --- a/bindings/Makefile.local
> +++ b/bindings/Makefile.local
> @@ -10,7 +10,7 @@ ifeq ($(HAVE_RUBY_DEV),1)
>                 LIBNOTMUCH="../../lib/$(LINKER_NAME)" \
>                 NOTMUCH_SRCDIR='$(NOTMUCH_SRCDIR)' \
>                 $(RUBY) extconf.rb --vendor
> -       $(MAKE) -C $(dir)/ruby
> +       $(MAKE) -C $(dir)/ruby CFLAGS="$(CFLAGS) -pipe -fno-plt -fPIC"

forget my suggestion -- also in general, usually, make variables have more
"power" than defining such a thing in environment (would not be in those
cases there is intermediate wrapper which does not get the make variable...)

Tomi

>  endif
>
> We lose -march=x86-64 -mtune=generic (at least on my machine), but I
> guess that's not a big deal since libnotmuch itself isn't getting
> compiled with those.
>
> I'll send a patch soonish.
>
> -- 
> Felipe Contreras
> _______________________________________________
> notmuch mailing list -- notmuch@notmuchmail.org
> To unsubscribe send an email to notmuch-leave@notmuchmail.org