Re: libtool problem

Alice Wonder <[email protected]>
Newsgroups gmane.comp.gnu.libtool.general
Message-ID <[email protected]>
I think the problem must be with audacity.

I tried building several other packages with the new gcc, including orc 
from the GStreamer project that requires libtool to build and I made 
sure (in mock buildroot) that only the /opt/gnu/bin/libtool I built was 
available - and they compiled, passed test suites, etc.

It's audacity that has a problem - even the older version that builds 
with system gcc has same tag error when building against the newer gcc 
in /opt/gnu. So something about the macros does not seem to like gcc 
installed outside of /usr

autoreconf -fvi results in an error about undefined macros.

aclocal --force -I /opt/gnu/share/aclocal -I m4
autoconf

That results in a configure script but it produces the same tag error.

So I'm going to see if anyone on their list knows what the issue is 
because the gcc definitely works, even when autoconf and libtoolize are 
needed, in other software.

I'll figure it out, the errors from autoreconf at least give me some 
hints as to what in their build scripts may need patching.

Thank you for that tip.

On 2018-06-26 14:51, Robert Boehne wrote:
> You are somehow mixing parts of libtool from different versions.
> --tag has been required since version 1.5, so some part of what you've
> built uses something even older, circa 2002.  First, try re-generating
> the configury for this project using newish tools.  'autoreconf" might
> do it.  You may also contact the project for the package you are
> trying to build, you might have missed some documentation that may
> tell you how to build it.
> 
> On Tue, Jun 26, 2018 at 4:09 PM, Alice Wonder <[email protected]>
> wrote:
> 
>> Hello,
>> 
>> Very low bandwidth user, my only connection is using my phone as a
>> hotspot which limits me to ~60 Kbits once I use the very low monthly
>> allotment (that broadband users usually have used in two days)
>> 
>> I have tried to search web for answers but it is very difficult as
>> many sites pull in heavy third party resources.
>> 
>> Okay -
>> 
>> Platform: CentOS 7.5 x86_64 building inside of mock (necessary
>> repositories locally mirrored while borrowing bandwidth from
>> library, I can keep they rsynced at my slow speed at night so they
>> are current)
>> 
>> Software (audacity) - older version require insecure dependency EPEL
>> removed due to its insecurity, building against newer results in GUI
>> that doesn't work.
>> 
>> Latest version of audacity requires GCC 4.9 or newer.
>> 
>> So I built a GCC 5.5.0 w/ prefix of /opt/gnu - it's built w/o
>> multilib and with just c,c++,objc,objc++ support (I probably only
>> need the first two)
>> 
>> With that gcc specified I get this error:
>> 
>> -- terminal output --
>> gtk/FileDialogPrivate.cpp: In function 'void
>> gtk_filedialog_ok_callback(GtkWidget*, FileDialog*)':
>> gtk/FileDialogPrivate.cpp:103:22: warning: ignoring return value of
>> 'int chdir(const char*)', declared with attribute warn_unused_result
>> [-Wunused-result]
>> chdir(folder);
>> ^
>> /bin/sh ./libtool    --mode=link g++    -L/opt/gnu/lib64 -L/lib64
>> -L/usr/lib64 -o libFileDialog.la -rpath /usr/lib64
>> libFileDialog_la-FileDialog.lo
>> gtk/libFileDialog_la-FileDialogPrivate.lo    -lgtk-3 -lgdk-3
>> -latk-1.0 -lgio-2.0 -lpangocairo-1.0 -lgdk_pixbuf-2.0
>> -lcairo-gobject -lpango-1.0 -lcairo -lgobject-2.0 -lglib-2.0
>> -lgtk-3 -lgdk-3 -latk-1.0 -lgio-2.0 -lpangocairo-1.0
>> -lgdk_pixbuf-2.0 -lcairo-gobject -lpango-1.0 -lcairo -lgobject-2.0
>> -lglib-2.0
>> libtool: link: unable to infer tagged configuration
>> libtool: link: specify a tag with `--tag'
>> make[2]: *** [libFileDialog.la] Error 1
>> -- /terminal output --
>> 
>> Looking at http://metastatic.org/text/libtool.html [1] from search
>> results, I built libtool 2.4.2 (same version CentOS 7 has) rpm from
>> pristine source but with a prefix of /opt/gnu and I built it using
>> the gcc 5.5.0 in /opt/gnu
>> 
>> Still get same error when specifying that libtool to audacity
>> configure.
>> 
>> Looking at audacity, seems they make their own libtool script. I
>> read it trying to find where the error might be.
>> 
>> Found the line
>> 
>> -- code --
>> sys_lib_dlsearch_path_spec="/lib /usr/lib /opt/gnu/lib64 "
>> -- /code --
>> 
>> Now after configure I try this but still get same error:
>> 
>> -- code --
>> sed -i -e 's?^sys_lib_dlsearch_path_spec="/lib
>> /usr/lib?sys_lib_dlsearch_path_spec="/lib64 /usr/lib64?g' libtool
>> 
>> -- /code --
>> 
>> I know the gcc 5.5.0 build works, I tested that with simple
>> 
>> echo 'int main(){}' > dummy.c
>> 
>> I do however suspect the error is somewhere on my end. Any
>> suggestions?
>> 
>> Full environmental variables I'm passing to audacity configure
>> script:
>> 
>> -- code --
>> LIBTOOL=/opt/gnu/bin/libtool CC=/opt/gnu/bin/gcc
>> CXX=/opt/gnu/bin/g++ CPP=/opt/gnu/bin/cpp LDFLAGS="-L/opt/gnu/lib64"
>> CPPFLAGS="-I/opt/gnu/include"
>> -- /code --
>> 
>> --
>> You have to be a deviant or exist in dreary boredom. Make no
>> mistake; all intellectuals are deviants -- William S. Burroughs
>> 
>> _______________________________________________
>> https://lists.gnu.org/mailman/listinfo/libtool [2]
> 
> 
> 
> Links:
> ------
> [1] http://metastatic.org/text/libtool.html
> [2] https://lists.gnu.org/mailman/listinfo/libtool

-- 
You have to be a deviant or exist in dreary boredom. Make no mistake; 
all intellectuals are deviants -- William S. Burroughs

_______________________________________________
https://lists.gnu.org/mailman/listinfo/libtool
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.