octave-bug-tracker
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Octave-bug-tracker] [bug #59173] "mkoctfile -p" returns wrong LDFLAGS o


From: Rik
Subject: [Octave-bug-tracker] [bug #59173] "mkoctfile -p" returns wrong LDFLAGS on Windows
Date: Mon, 28 Sep 2020 18:47:15 -0400 (EDT)
User-agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/85.0.4183.83 Safari/537.36

Update of bug #59173 (project octave):

                  Status:                    None => Patch Submitted        

    _______________________________________________________

Follow-up Comment #13:

Yes, it should be no worse than what exists today.  The option 


-Wl,-rpath-link,/scratch/build/release/mxe-octave-w64/usr/x86_64-w64-mingw32/lib


sends the option "-rpath-link=directory" to the linker.  Given that the
directory mentioned is never going to be valid (it was a temporary scratch
directory used during the cross build) I can't see it mattering.

Of course, the real test is whether mkoctfile will correctly compile packages
like sparsersb with such a configuration.

I'm attaching a changeset that implements the suggestion to switch between the
environmental variable LDFLAGS (if defined) and a DEFAULT_LDFLAGS variable
that is correctly set for the host.  It turns out that we were already using
this coding pattern for INCFLAGS so I think it will work.

In any case, the patch is attached and if you could check it that would help.

(file #49881)
    _______________________________________________________

Additional Item Attachment:

File name: 59173.cset                     Size:2 KB
    <https://file.savannah.gnu.org/file/59173.cset?file_id=49881>



    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/bugs/?59173>

_______________________________________________
  Message sent via Savannah
  https://savannah.gnu.org/




reply via email to

[Prev in Thread] Current Thread [Next in Thread]