Tue 21 Jun 2016 04:49:22 PM UTC, comment #15:
Thanks for the followups. I think I may have confused myself earlier also.
In any case, the "builddir" is always going to be the current directory when you are building Octave. So the bare directory "libinterp" refers to the libinterp subdir in the build directory, and since we now do non-recursive building, that is always correct. It could also be spelled "./libinterp", but either way the build directory is always the current directory.
I'm not sure about the "libinterp/octave" name, though, but unless/until someone reports an error with that set of options I don't see a reason to change it for this bug.
Closing again, ok?
|
Tue 21 Jun 2016 07:52:33 AM UTC, comment #14:
Mike,
The patch is OK for me and I don't see any reason to change it.
But, just for completeness, I am NOT building with './configure' and my 'builddir' does not coincide with 'srcdir'.
I have a source directory named 'octave' and a build directory named 'build_default' which are on the same level and I run '../octave/configure' from within 'build_default' so in my case I guess '$builddir' should expand to '../build_default' or something similar?
|
Thu 16 Jun 2016 06:33:15 PM UTC, comment #13:
Hi Mike,
Here is what I get on MacOS with my proposed patch but only for
DL_LDFLAGS
MKOCTFILE_DL_LDFLAGS
i.e. without SHLEXT_VER, SHLLIB_VER and SHLBIN_VER.
With your patch it looks like this:
Please note that with your patch the leading / is missing, i.e.
libinterp/octave
vs.
/libinterp/octave
Friedrich
|
Thu 16 Jun 2016 06:22:53 PM UTC, comment #12:
I think this variable is actually only used now when cross-compiling, and I think the path used to be correct when "libinterp" was "src", possibly something got lost along the way.
|
Thu 16 Jun 2016 06:17:57 PM UTC, comment #11:
Thanks. That's actually what I intended it to be, since it should be $builddir/libinterp/octave, and assuming you built with ./configure, that's right. I think this variable is mainly used for building things inside the build tree, so that is correct as far as it should be.
Now if that variable is not actually used anywhere, or not really needed in octave_config_info, maybe we can delete that like the other obsolete build vars I cut out recently.
I've pushed this on default now, thanks to both of you for the patches and testing.
http://hg.savannah.gnu.org/hgweb/octave/rev/a53f46577e39
|
Thu 16 Jun 2016 05:36:48 PM UTC, comment #10:
Mike,
With your changeset applied I still get:
This does not look right to me, does it?
|
Thu 16 Jun 2016 04:23:02 PM UTC, comment #9:
Here is what I get:
indeed the value in _octave_config_info_ does look a bit fishy, I'll try your changeset instead.
|
Thu 16 Jun 2016 03:45:16 PM UTC, comment #8:
Sorry for asking for one more round of testing. I think there are still some small problems with this change and I want to be sure to get them all.
What are the values of
with the current proposed patch applied? I suspect the octave_config_info value may not quite correct.
Please try the attached changeset instead, which is what I intend on pushing if it works for you. This should expand the variable values at the right time for both sets of flags.
(file #37504)
|
Thu 16 Jun 2016 08:57:32 AM UTC, comment #7:
Mike, Friederich,
The patch seems to fix the issue for me, now
with the patch applied I get:
and, after build, I get a working mkoctfile.
Thanks Friederich for this fix, I think it should be pushed ASAP.
c.
|
Wed 15 Jun 2016 05:57:38 PM UTC, comment #6:
Carlo, thanks for pointing to that earlier thread. No replies, maybe not many macOS users are working from the default branch?
I'll wait for results from your test of the patch. It looks good to me, I'd maybe add a comment to separate the earlier variables which are all "dir" variables from these build flag variables.
I've also now deleted all the other variables touched by this patch, since they are completely obsolete and unused.
|
Wed 15 Jun 2016 10:39:26 AM UTC, comment #5:
Hi,
This is the same problem I had reported here:
http://octave.1599824.n4.nabble.com/DL-LDFLAGS-td4676998.html
I was not sure whether it was a bug as I was (and still am) very surprised that no other OSX users were seeing the same issue!
I'll test the patch and report back.
|
Tue 14 Jun 2016 01:02:41 PM UTC, comment #4:
Looking at the mentioned patch, all variables which use "version" will expand to zero if they are set before line 8.156. Therefore 8.50, 8.51 and 8.52 should not work. SHLEXT_VER will yield "so.", because version is not set at that point.
Mike questioned that these variable are useful at all because they are maybe not be used. I cannot judge that. But from my perspective the mentioned change
http://hg.savannah.gnu.org/hgweb/octave/rev/1aa293d58df0
is not correct for the variables SHLEXT_VER, SHLLIB_VER and SHLBIN_VER.
The variables
DL_LDFLAGS
MKOCTFILE_DL_LDFLAGS
do not work for the MacOS case which was not considered in the patch. For the MacOS case they use the "version" variable and the "top_builddir" or "bindir" variable. The setting itself is o.k., i.e. when this is fully expanded, then it works for me in macports.
|
Tue 14 Jun 2016 11:47:37 AM UTC, comment #3:
I'm not sure of the correct setting of the flags for OS X, but if these variables need things like ${bindir} or ${version} embeded in them, then the patch is the right thing to do.
See also bug #46063 and http://hg.savannah.gnu.org/hgweb/octave/rev/1aa293d58df0
|
Mon 13 Jun 2016 08:07:41 PM UTC, comment #2:
Hi Mike,
thanks for your comment. I only left the changes to MKOCTFILE_DL_LDFLAGS and DL_LDFLAGS and then still mkoctfile works for me. So I cannot see what is not working when the other variables are not changed.
Friedrich
|
Mon 13 Jun 2016 03:50:10 PM UTC, comment #1:
Thanks for the detailed bug report and patch. It does look like some form of expansion is needed for DL_LDFLAGS and MKOCTFILE_DL_LDFLAGS on OS X. Only OS X contains variable expansions within those variable definitions. Can any other OS X users confirm that something needs to be fixed here for building oct-files or mex-files?
The other variables (SHLEXT_VER, SHLLIB_VER, and SONAME_FLAGS) don't even seem to be used anywhere in Octave anymore, they may be completely obsolete. I wouldn't change anything in those unless you can show that they are used and necessary for your use case.
|
Mon 13 Jun 2016 12:28:30 PM UTC, original submission:
Hi,
i tried to use the development version octave-devel on macports for building octave 4.1.0+ which is hg version 19e8eddd4773 on MacOS.
The following error is produced, when I use mkoctfile to compile a mex file
The reason for the problem is a wrong setting of the MKOCTFILE_DL_LDFLAGS variable in configure.ac. The reason for that is that the variable "version" is not set at that point of time - it is empty. The handling of variables like "octfiledir" is different, as these variables are taken first literally, i.e. ${version} is not expanded at that point of time, but later after version has been set to OCTAVE_VERSION in line 3351, they are expanded.
The same problem is there for other variables. I made a patch versus the configure.ac version that is already patched in macports, so the line numbers may vary vs. the current hg version.
The patch follows the idea of the directory variables which are explicitly expanded.
I tested this in the macports environment and there I can compile the mex files with this patch.
|