bugGNU Octave - Bugs: bug #61905, Build fails when using slibtool...

 
 

bug #61905: Build fails when using slibtool instead of GNU libtool

Submitted by:  Michael Orlitzky <mjo>
Submitted on:  Mon 24 Jan 2022 01:07:53 AM UTC
 
Category:  Configuration and Build System Severity:  3 - Normal
Priority:  5 - Normal Item Group:  None
Status:  Fixed Assigned to:  None
Originator Name:  Open/Closed:  * Closed
Release:  * dev Operating System:  * Any
* Mandatory Fields

Add a New Comment (Rich Markup)
   

Comment Type & Canned Response:
       

 

( Jump to the original submission )

Fri 18 Mar 2022 08:16:09 AM UTC, comment #31: 

@mjo: I'm not sure if I understood correctly. But I'm taking this as a confirmation that the change works for you using `slibtool`.
Please, let us know if that is not the case. We'll re-open this report in that case.

Closing as fixed.

Markus Mützel <mmuetzel>
Project Member
Thu 17 Mar 2022 02:47:36 PM UTC, comment #30: 

Ok, I'll take what I can get, thanks =)

I built octave-6.4.0 successfully and pushed the patch out on Gentoo for testing.

Michael Orlitzky <mjo>
Wed 16 Mar 2022 05:21:32 PM UTC, comment #29: 

From the documentation of slibtool:
https://github.com/midipix-project/slibtool

>- `.la wrappers` are always generated, but by default are never installed;
>  `.la wrappers` contain key information that is provided to libtool when
>  generating a shared library or static archive, and which is needed when
>  passing the archive or library as an input argument in .la form to the
>  compiler driver in subsequent link steps. Since `slibtool` is entirely
>  independent of the above wrappers with respect to its own functionality,
>  and given its announced goal to remain compatible with the script-based
>  libtool as much as possible, `slibtool`'s behavior is to always produce
>  `.la wrappers` on the one hand, yet fully ignore their content on the
>  other.


So, .la files are still produced and are compatible with `libtool`. (If they are not, that is probably a bug in `slibtool`.)
The major difference is that .la files aren't installed by `slibtool`.
We probably shouldn't rely on those files being installed anyway.

I pushed the following change that parses the .la file in the build tree instead:
https://hg.savannah.gnu.org/hgweb/octave/rev/2d394460429f

That should allow building Octave with `slibtool` while maintaining compatibility with all platforms that we currently support.

Marking as ready for test.

Markus Mützel <mmuetzel>
Project Member
Fri 11 Feb 2022 12:36:17 PM UTC, comment #28: 

comment #27:

> Is it possible to write those rules in a way that works correctly across different platforms and compilers (GCC, clang, Apple clang, Intel C++, IBM, ...)? (We definitely don't have the resources to test that reliably.) Isn't that the reason something like `libtool` exists in the first place?


Libtool handles a lot of things, but most of them aren't a concern for oct files. Do I understand correctly that they're always built as shared libraries so that they can be loaded dynamically?

If so, some of libtool's features that AREN'T needed are,

  * Build system support for --disable-shared
  * Old operating systems without support for shared libraries at all
  * Hacking of the library search path so that you can run the program
    before installing it (not an issue with dlopen).
  * Figuring out the correct prefix and suffix for the library files
    on the current system (always foo.oct).
  * Library (soname) versioning.

It DOES also play a part in the command used to build the libraries... and, you've caught me: I can't make any promises about proprietary compilers that I don't have access to. But the command-line that libtool constructs is a fairly standard one consisting of $CC, $CFLAGS, $LDFLAGS, $LIBS, etc, all in the proper order -- most of the magic therefore takes place in constructing those variables. For example, you don't want to pass -fpic to a compiler that doesn't support it; but that can be tested with autoconf, with or without libtool. Some of the more basic flags (like -c and -o) are covered by the POSIX description of "cc", so IIRC you're mainly relying on -shared and -fpic.

The admins of older systems that I know have all bootstrapped themselves a modern(ish) toolchain, but YMMV. It would be a larger change and it would require testing, obviously. I'm just throwing it out there =)

> > IMO this is a lesser evil and a bargain for removing the .la file parsing from the install-oct target.
>
> I agree that parsing the .la file might not be the best solution. But I'm not sure which approach would be the better one in the long run: Relying on the layout of the .la file, or implementing and maintaining build rules for the different combinations of compilers and platforms ourselves instead of relying on tools like `libtool`?


I'm only comparing the status quo against my most recent patch. The potential downside to the patch is that some other stray libtool artifacts may be discovered on an obscure platform, and the glob will have to be updated to remove them. Since those artifacts are harmless in the meantime (and may never materialize in the first place), I don't see this as a huge problem, but I'm biased.

Michael Orlitzky <mjo>
Fri 11 Feb 2022 08:16:58 AM UTC, comment #27: 

> Unless you're targeting systems from the early 90s, $(CC) <whatever> works fine and gives you only the file you want in the place you expect.


Is it possible to write those rules in a way that works correctly across different platforms and compilers (GCC, clang, Apple clang, Intel C++, IBM, ...)? (We definitely don't have the resources to test that reliably.) Isn't that the reason something like `libtool` exists in the first place?

> IMO this is a lesser evil and a bargain for removing the .la file parsing from the install-oct target.


I agree that parsing the .la file might not be the best solution. But I'm not sure which approach would be the better one in the long run: Relying on the layout of the .la file, or implementing and maintaining build rules for the different combinations of compilers and platforms ourselves instead of relying on tools like `libtool`?

Markus Mützel <mmuetzel>
Project Member
Tue 08 Feb 2022 12:23:17 PM UTC, comment #26: 

comment #25:

> I haven't tested the latest patch yet. But I'm not sure if it is the right approach when it comes to portability.


Probably not. I think libtool shouldn't be used at all for these *.oct libraries; the extra libtool pieces just get in the way. Unless you're targeting systems from the early 90s, $(CC) <whatever> works fine and gives you only the file you want in the place you expect. Losing the automake magic for those libs would hurt a bit, but the corresponding rule can basically be copy & pasted out of the generated Makefile.in.

> The following naming conventions seem to be used at least by autotools and cmake for "mingw*" targets


Those are all covered...

> Afaict from a Google search, the naming conventions are the following for a msvc target (using cmake?). (That could be wrong though):
> * static library: foo-static.lib
> * shared library: foo.dll
> * import library: foo.lib


Those .lib files would not be. But the worst thing that can possibly happen is that some unused files get installed until the next release when the rule can be updated. IMO this is a lesser evil and a bargain for removing the .la file parsing from the install-oct target.

Michael Orlitzky <mjo>
Tue 08 Feb 2022 09:19:46 AM UTC, comment #25: 

I haven't tested the latest patch yet. But I'm not sure if it is the right approach when it comes to portability.

The following naming conventions seem to be used at least by autotools and cmake for "mingw*" targets for a library "foo" in their current versions (other naming conventions might be used by other build tools or other Windows targets like e.g. "msvc"):

  • static library: libfoo.a
  • shared library: libfoo.dll
  • import library: libfoo.dll.a

All of those are sometimes versioned as e.g. something like libfoo-1.dll.
Those naming conventions might be implementation details though. (Maybe even more so than the .la file format.)

Afaict from a Google search, the naming conventions are the following for a msvc target (using cmake?). (That could be wrong though):

  • static library: foo-static.lib
  • shared library: foo.dll
  • import library: foo.lib

You might be right that the import libraries are technically static libraries (from a file format point of view). But they are rarely referred to as such because they are used for something rather different.

There is nothing that corresponds to Windows import libraries on Linux. As far as I know, `LIBEXT` is the default extension for static libraries (i.e., `.a` for mingw* targets). I don't know if there is a readily available variable that tells which extension libtool is using for import libraries.

Markus Mützel <mmuetzel>
Project Member
Tue 08 Feb 2022 12:56:27 AM UTC, comment #24: 

comment #23:

> They're still technically shared libraries,


static, obviously

Michael Orlitzky <mjo>
Tue 08 Feb 2022 12:55:44 AM UTC, comment #23: 

They're still technically shared libraries, which gives me hope that we can predict their names portably, even if this only happens on one platform.

The new patch should do the right thing on Windows (supposing autoconf sets the variables how I think it will), and on linux with --enable-static appended to ./configure. It likely will not work with both --disable-shared --enable-static, but the vanilla build already fails for me when I try that, so I've punted.

(file #52821)

Michael Orlitzky <mjo>
Mon 07 Feb 2022 07:11:57 PM UTC, comment #22: 

The import libraries are not exactly static libraries. They are more like "thin wrappers" that are needed to be linked in "like" static libraries to allow calling functions from DLLs.
See e.g.: https://www.sourceware.org/autobook/autobook/autobook_137.html

Markus Mützel <mmuetzel>
Project Member
Mon 07 Feb 2022 07:09:15 PM UTC, comment #21: 

If I recall correctly, the dll.a file is not because of static libraries, but it is a part of the way that DLLs are handled on that platform.

I'm fairly sure that the .la files must be in a predictable location.  They are the files used by automake as targets for rules involving libtool.

John W. Eaton <jwe>
Project Administrator
Mon 07 Feb 2022 06:56:24 PM UTC, comment #20: 

I think the extra dll.a may just be due to that platform enabling static libraries by default. That's something we need to handle on linux anyway if "--enable-static" was given. I'm testing that now.

Michael Orlitzky <mjo>
Mon 07 Feb 2022 06:32:58 PM UTC, comment #19: 

Not sure if this counts as "documentation". But the variables that are set in a .la file are listed in the sources here:
https://git.savannah.gnu.org/cgit/libtool.git/tree/build-aux/ltmain.in#n5981

        dlname=
        dlopen=
        dlpreopen=
        libdir=
        library_names=
        old_library=
        inherited_linker_flags=
        # If the library was installed with an old release of libtool,
        # it will not redefine variables installed, or shouldnotlink
        installed=yes
        shouldnotlink=no
        avoidtemprpath=

Markus Mützel <mmuetzel>
Project Member
Mon 07 Feb 2022 06:17:36 PM UTC, comment #18: 

comment #16:

> Reading up a bit on slibtool: Is it true that it still creates .la files but doesn't install them?


Right.

>Is the content of that file compatible with GNU libtool?


It looks similar, but I don't know for sure. Is either format documented?

> In that case, would it be possible to parse the .la file in the build tree instead of in the installation tree and gather the necessary information to handle the files in the installation tree from there?


I think the reason why install-oct does this stuff inside the installation image in the first place is because the layout of the build tree is platform-dependent. I don't know that the *.la files will be in a predictable place. (But yes, if you can find them and if they're compatible, this might work.)

Michael Orlitzky <mjo>
Mon 07 Feb 2022 06:12:25 PM UTC, comment #17: 

comment #15:

> However, the import libraries are installed to $(DESTDIR)$(octlibdir). So, the command from comment #14 would probably be a no-op.
> There are a couple of other files installed to $(DESTDIR)$(octlibdir) that we need to keep.


I see, thanks.

Does "dll.a" appear in any of the autoconf mumbo jumbo on that platform (like how "dll" appears as acl_shlibext)? If we have that information, my next choice would be to delete those files specifically from within $(octlibdir).

Otherwise, if there's no collateral damage, I could rm ${f_so}.*, to catch the ".a" at the end.

Finally, if neither of those will work... we're going to wind up hard-coding something. Either libtool internals, or the alternate names of libraries to delete. Since the extra libraries are harmless, it wouldn't be too ugly to delete them based on the dll.a extension. This would still be my last resort though. (The problem with slibtool is that there is no installed la file to parse.)

Michael Orlitzky <mjo>
Mon 07 Feb 2022 06:06:50 PM UTC, comment #16: 

Reading up a bit on slibtool: Is it true that it still creates .la files but doesn't install them? Is the content of that file compatible with GNU libtool?
In that case, would it be possible to parse the .la file in the build tree instead of in the installation tree and gather the necessary information to handle the files in the installation tree from there?

Markus Mützel <mmuetzel>
Project Member
Mon 07 Feb 2022 05:53:37 PM UTC, comment #15: 

> is there any reason for a non-oct file to ultimately wind up installed to $(DESTDIR)$(octfiledir)?

Afaict, no other files than .oct files are installed to that location.
However, the import libraries are installed to $(DESTDIR)$(octlibdir). So, the command from comment #14 would probably be a no-op.
There are a couple of other files installed to $(DESTDIR)$(octlibdir) that we need to keep.

Markus Mützel <mmuetzel>
Project Member
Mon 07 Feb 2022 05:48:45 PM UTC, comment #14: 

comment #13:

>
> More seriously: I don't know of a cross-platform way to get that info. `libtool` hides all of that usually. But it's different in this case unfortunately.


Ok, back to the drawing board: is there any reason for a non-oct file to ultimately wind up installed to $(DESTDIR)$(octfiledir)? If not,

find $(DESTDIR)$(octfiledir) -type f ! -name '*.oct' -delete

should do the trick without hard-coding any specific platform details.

Michael Orlitzky <mjo>
Mon 07 Feb 2022 04:14:15 PM UTC, comment #13: 

> Do you have any idea about the best way to accomplish that?

Well, you could parse the .la file... 😉

I'm attaching one of the .la files from the Windows build just in case. Afaict, it's the `lnames` read from the line starting with `library_names=` in the old/current rule.

More seriously: I don't know of a cross-platform way to get that info. `libtool` hides all of that usually. But it's different in this case unfortunately.

IIUC, the extension for import libraries might be different on Windows depending on whether the library is built with a mingw/GCC-toolchain or with MSVC (`.lib`?). Even if I don't know of anyone is currently building Octave with MSVC, hard-coding `.dll.a` probably isn't a good idea either...

(file #52820)

Markus Mützel <mmuetzel>
Project Member
Sun 06 Feb 2022 10:00:42 PM UTC, comment #12: 

comment #11:

> However, the import libraries (ending with ".dll.a" for mingw on Windows) still remain at their original installation location when the installation has finished. IIUC, we'd like to get rid of those. (They'll probably not be useful anyway after their corresponding dynamic link libraries are renamed and moved.)


Do you have any idea about the best way to accomplish that? I don't have much experience on Windows these days; and maybe more importantly, I can't test it.

> I also agree with jwe that it would probably be safer to keep using `install` when messing with installed files.


Certainly while installing files from the build tree to the installation image this is true, but within the installation image it has the downside of causing unnecessary copies, chmods, and chowns. I won't die on that hill but it bears mentioning.

Michael Orlitzky <mjo>
Sun 06 Feb 2022 10:16:54 AM UTC, comment #11: 

I tested your patch on Windows with MSYS2/MINGW64 bash. It's often the "odd-one-out".
The libraries are correctly renamed and moved to the correct destination on installation.
However, the import libraries (ending with ".dll.a" for mingw on Windows) still remain at their original installation location when the installation has finished. IIUC, we'd like to get rid of those. (They'll probably not be useful anyway after their corresponding dynamic link libraries are renamed and moved.)

I also agree with jwe that it would probably be safer to keep using `install` when messing with installed files.

Markus Mützel <mmuetzel>
Project Member
Sat 05 Feb 2022 03:59:31 PM UTC, comment #10: 

comment #9:

>
> I'm also not sure how portable $(foo%X}Y is.
>


It's POSIX,

https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html

but I've only verified it with the shells that are available on a modern linux system.

Michael Orlitzky <mjo>
Sat 05 Feb 2022 03:53:08 PM UTC, comment #9: 

I assume that when the install-oct target was written, looking in the .la file seemed to be the only reliable way to get the name of the shared library file.

Using mv here is probably OK as long as the original shared library file has the correct permissions and they are preserved when moving to the new name.  Otherwise, I would still use $(INSTALL_PROGRAM).

I'm also not sure how portable $(foo%X}Y is.

John W. Eaton <jwe>
Project Administrator
Fri 04 Feb 2022 10:15:29 PM UTC, comment #8: 

Thanks for the pointer. If I read that right, it's not even installing the oct files from the build tree. Instead it's cd'ing into the installation image and using INSTALL_PROGRAM as a fancy "cp" to copy foo.so to foo.oct.

Of course I'm guessing, but I suppose this was done to abstract away the actual names of the shared libraries (which are platform dependent). Fortunately that information is already available to the build system. I've attached a patch that exploits the knowledge of the shared library name, and replaces most of the install-oct rule with a single "mv". It doesn't seem to have broken anything else, but someone with more octave experience will have to confirm.

(file #52806)

Michael Orlitzky <mjo>
Tue 01 Feb 2022 07:52:00 PM UTC, comment #7: 

Regarding configuring with `--enable-link-all-dependencies`: IIUC, it would probably be better if you configured with `--disable-no-undefined` instead. Unless you are building for one of the host systems listed in comment #3...

Markus Mützel <mmuetzel>
Project Member
Tue 01 Feb 2022 07:26:34 PM UTC, comment #6: 

`hg annotate` indicated that that logic was added with this changeset:
https://hg.savannah.gnu.org/hgweb/octave/rev/b4cb9d04f3cf

That was after Octave 6 was released. So, it will be new for Octave 7.

Regarding the .la file: I'm not sure I correctly understand. I hope someone will chime in if this complete nonsense.
Some background: Octave can be extended with library functions called .oct files. Essentially, those files are shared library like any other .so on a Linux system. But they have a special interface that allows them to be called from the Octave interpreter. To make it possible to distinguish them from any old .so file, those files end in ".oct". We'd like that these .oct files are installed (not the corresponding .so file in the .libs folder).
My guess is that `make install` (without those rules) would install the .so files.

For a test, I tried removing that rule:

diff -r 66456820ff59 Makefile.am
--- a/Makefile.am        Mon Jan 31 17:27:19 2022 +0100
+++ b/Makefile.am        Tue Feb 01 20:25:32 2022 +0100
@@ -455,25 +455,7 @@
           && mv $@-t $@

 install-oct: oct-file-pkg-add
-        $(MKDIR_P) $(DESTDIR)$(octfiledir)
-        if [ -n "`cat $(OCT_FILE_PKG_ADD_FILES)`" ]; then \
-          $(INSTALL_DATA) oct-file-pkg-add $(DESTDIR)$(octfiledir)/PKG_ADD; \
-        fi
-        cd $(DESTDIR)$(octlibdir) && \
-        for ltlib in $(OCT_FILE_LIBS); do \
-          f=`echo $$ltlib | $(SED) 's,.*/,,'`; \
-          dl=`$(SED) -n -e "s/dlname='\([^']*\)'/\1/p" < $$f`; \
-          if [ -n "$$dl" ]; then \
-            $(INSTALL_PROGRAM) $$dl $(DESTDIR)$(octfiledir)/`echo $$f | $(SED) 's,^lib,,; s,\.la$$,.oct,'`; \
-          else \
-            echo "error: dlname is empty in $$ltlib!"; \
-            exit 1; \
-          fi; \
-          lnames=`$(SED) -n -e "s/library_names='\([^']*\)'/\1/p" < $$f`; \
-          if [ -n "$$lnames" ]; then \
-            rm -f $$f $$lnames $$dl; \
-          fi \
-        done
+        echo Hello install-oct
 .PHONY: install-oct

 uninstall-oct:

With the effect that the .so files are installed (not the .oct files).

Markus Mützel <mmuetzel>
Project Member
Tue 01 Feb 2022 06:51:56 PM UTC, comment #5: 

comment #3:

> I don't remember what the default for `--enable-no-undefined` was in the past. But that might have been fixed in the meantime(?).
> Afaict currently on the stable branch (will become Octave 7), the configure script only sets the corresponding linker flags to something non-empty by default for msdosmsvc, mingw*, AIX, BeOS, or OS/2. Are you building for one of those hosts?


No, I could be wrong about that part. Out of the box, Octave failed to build with slibtool due to undefined symbols, and adding --enable-link-all-dependencies fixed it. At that point I savoured my temporary victory and failed to check the other flag combinations. So maybe it crashes regardless of --enable-no-undefined.

> I can't comment on the sed replacement in the .la files.
> I don't know anything about slibtool or how it differs from GNU libtool. Could you please elaborate why that doesn't work for you, or how this should be done differently so it would work for both tools?


Why what doesn't work for me? There's probably a more portable alternative, but I'd need to know what problem the sed is intended to fix first, i.e. what goes wrong if you skip it and just make the automake "make install" do its thing?

Michael Orlitzky <mjo>
Tue 01 Feb 2022 05:13:32 PM UTC, comment #4: 

Regarding the long time without a new version of GNU libtool: It looks like it got a new maintainer a few weeks/months ago:
https://lists.gnu.org/archive/html/libtool/2021-10/msg00007.html

And there seems to be some activity in the Git repository since mid-November after a hiatus of more than two and a half years:
https://git.savannah.gnu.org/cgit/libtool.git/log/

Maybe that means there'll be an updated release in due time fixing some of the bugs you are worried about.

This could be the time to get those patches upstreamed (if they aren't yet).

Markus Mützel <mmuetzel>
Project Member
Tue 01 Feb 2022 04:09:37 PM UTC, comment #3: 

I don't remember what the default for `--enable-no-undefined` was in the past. But that might have been fixed in the meantime(?).
Afaict currently on the stable branch (will become Octave 7), the configure script only sets the corresponding linker flags to something non-empty by default for msdosmsvc, mingw*, AIX, BeOS, or OS/2. Are you building for one of those hosts?
See also this part of the current configure script source:
https://hg.savannah.gnu.org/hgweb/octave/file/66456820ff59/configure.ac#l676

case $host_os in
  msdosmsvc | mingw* | AIX | BeOS | OS/2 )
    DEFAULT_NO_UNDEFINED_LDFLAG="-no-undefined"
  ;;
  *)
    DEFAULT_NO_UNDEFINED_LDFLAG=""
  ;;
esac
AC_ARG_ENABLE([no-undefined],
  [AS_HELP_STRING([--enable-no-undefined],
    [pass -no-undefined to libtool when linking Octave and its shared libraries. This is done by default for msdosmsvc, mingw*, AIX, BeOS, or OS/2 hosts.])],
  [case $enableval in
     yes) NO_UNDEFINED_LDFLAG="-no-undefined" ;;
     no)  NO_UNDEFINED_LDFLAG="" ;;
     *) AC_MSG_ERROR([bad value $enableval for --enable-no-undefined]) ;;
   esac],
  [NO_UNDEFINED_LDFLAG="$DEFAULT_NO_UNDEFINED_LDFLAG"])
AC_SUBST(NO_UNDEFINED_LDFLAG)

I can't comment on the sed replacement in the .la files.
I don't know anything about slibtool or how it differs from GNU libtool. Could you please elaborate why that doesn't work for you, or how this should be done differently so it would work for both tools?

Markus Mützel <mmuetzel>
Project Member
Mon 24 Jan 2022 01:09:03 PM UTC, comment #2: 

There's no immediate problem, but we've accrued fifteen patches for GNU libtool:

  https://gitweb.gentoo.org/repo/gentoo.git/tree/sys-devel/libtool/files

The "libtool" script also hard-codes some important variables like CC and CFLAGS that can cause problems if the user e.g. tries to use clang after building libtool libtool with gcc. In short, it's just getting annoying.

So we've tried to build the entire distro with slibtool instead:

  https://bugs.gentoo.org/show_bug.cgi?id=slibtool

This has found lots of build system bugs, and a few slibtool bugs. But most packages build out-of-the-box.

Being able to build octave with slibtool would be nice for users that want to use it (it's faster than GNU libtool), is good for portability (vanilla GNU libtool is seven years out of date w.r.t. new arches), and provides a nice check for correctness in the build system akin to testing with multiple compilers.

Michael Orlitzky <mjo>
Mon 24 Jan 2022 04:37:09 AM UTC, comment #1: 

"GNU libtool hasn't seen a release since 2015, so we've starting to look elsewhere."

Can you please explain why you need something different?  Exactly what problems do you face when building Octave?  Precisely how does libtool fail for you when building Octave?

John W. Eaton <jwe>
Project Administrator
Mon 24 Jan 2022 01:07:53 AM UTC, original submission:  

GNU libtool hasn't seen a release since 2015, so we've starting to look elsewhere. One promising replacement is the slibtool project written in C (https://dev.midipix.org/cross/slibtool). Let's try to build Octave...

First, slibtool is a bit more strict than GNU libtool. In particular, it doesn't silently discard the --no-undefined option. Thus the Octave defaults of

  --enable-no-undefined (default on)
  --enable-link-all-dependencies (default off)

conflict, since --enable-link-all-dependencies is required to eliminate the undefined. But with ./configure --enable-link-all-dependencies, we get pretty far:

for ltlib in libinterp/dldfcn/__delaunayn__.la libinterp/dldfcn/__fltk_uigetfile__.la libinterp/dldfcn/__glpk__.la libinterp/dldfcn/__init_fltk__.la libinterp/dldfcn/__init_gnuplot__.la libinterp/dldfcn/__ode15__.la libinterp/dldfcn/__voronoi__.la libinterp/dldfcn/audiodevinfo.la libinterp/dldfcn/audioread.la libinterp/dldfcn/convhulln.la libinterp/dldfcn/fftw.la libinterp/dldfcn/gzip.la; do \
  f=`echo $ltlib | /usr/bin//sed 's,.*/,,'`; \
  dl=`/usr/bin//sed -n -e "s/dlname='\([^']*\)'/\1/p" < $f`; \
  if [ -n "$dl" ]; then \
    /usr/lib/portage/python3.9/ebuild-helpers/xattr/install -c $dl /var/tmp/portage/sci-mathematics/octave-6.4.0/image//usr/lib64/octave/6.4.0/oct/x86_64-pc-linux-gnu/`echo $f | /usr/bin//sed 's,^lib,,; s,\.la$,.oct,'`; \
  else \
    echo "error: dlname is empty in $ltlib!"; \
    exit 1; \
  fi; \
  lnames=`/usr/bin//sed -n -e "s/library_names='\([^']*\)'/\1/p" < $f`; \
  if [ -n "$lnames" ]; then \
    rm -f $f $lnames $dl; \
  fi \
done
/bin/sh: 1: cannot open __delaunayn__.la: No such file
error: dlname is empty in libinterp/dldfcn/__delaunayn__.la!
make[4]: *** [Makefile:31893: install-oct] Error 1

Now at this point I see that the failed command is part of the install-oct target in Makefile.am. So I have to beg you to find some other way to accomplish the same thing without relying on GNU libtool's implementation details =)

Michael Orlitzky <mjo>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by mmuetzel (Posted a comment)
  • -email is unavailable- added by jwe (Posted a comment)
  • -email is unavailable- added by mjo (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only project members can vote.

     

     

     

     

    Follow 9 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2022-03-18 mmuetzel StatusReady For Test => Fixed
        Open/ClosedOpen => Closed
    2022-03-16 mmuetzel StatusNeed Info => Ready For Test
        Release6.4.0 => dev
        Operating SystemGNU/Linux => Any
    2022-02-08 mjo Attached File- => Added 0001-autotools-don-t-rely-on-libtool-internals-during-ins-v2.patch, #52821
    2022-02-07 mmuetzel Attached File- => Added _delaunayn_.la, #52820
    2022-02-04 mjo Attached File- => Added 0001-autotools-don-t-rely-on-libtool-internals-during-ins.patch, #52806
    2022-01-24 jwe StatusNone => Need Info

    Back to the top


    Powered by Savane 3.9