G'day Bruce: I think it would help you envision a solution in Libtool to look at what gcc builds currently do. I'm sure the gcc guys would like it if Libtool could handle all of the multilib combinat
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 b
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-
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
Thank you! Peter your comments pointed me in the right direction, CXX and LD in the env seem to be not needed --host is enough, LT_INIT need [win32-dll] and libexample_la_LDFLAGS need -no-undefined.
Any chance that this patch, or a patch that fixes bug #15321 [1], gets applied any time? -- O.S. [1] http://debbugs.gnu.org/cgi/bugreport.cgi?bug=15321
I can confirm that with this applied to libtool-git, I can build a dll using cross-toolchains on linux. The `libtool --config` output for sys_lib_search_path_spec contains, - for a i686-pc-mingw32 to
More background [1], [2]: Alan Modra hints in [1] that -print-search-dirs was fixed in GCC 4.2, so that it nowadays automatically appends -print-multi-os-directory for the applicable directories. I.e
No, it does not. With this patch applied, I see sys_lib_search_path_spec="/opt/W64_180676/lib/gcc " .. in the libtool --config output. (Note that, this is not a multilib compiler: it targets only win
Thanks, this one makes it to work. ./libtool --config output now has: sys_lib_search_path_spec="/opt/W64_180676/lib/gcc /opt/W64_180676/x86_64-w64-mingw32/lib64 /opt/cross_win64/mingw/lib64 /opt/W64_
They will break libtool for those using native MinGW compilers from with Cygwin or with Wine. Yes, some people do that sort of thing. That last hunk will evade the multilib loop by redoing the -print
A bunch of things? :-] Anyway, I could reproduce locally after I did: mkdir /usr/x86_64-w64-mingw32/sys-root/mingw/lib64 With that dir in place, libtool no longer finds any import libraries, and I ge
Michael, The "-brtl" isn't a "run-time linking" flag, but more exactly, it's a system-5 shared library compatibility mode flag. It is intended to provide a more familiar shared library style,
Hello! On AIX, with runtime linking (-brtl linker flag) enabled, the current way how libtool creates shared libraries prevents any form of "soname" support, as there is no way to have the runtime loa
I am not at all an expert on guile-config, but I will help if I can. Thank you to all who responded. Usually if you have 64-bit libs in lib64, you have to pass --libdir explicitly. We've now conclude
On OpenSolaris, like Solaris, the default it to build 32-bit objects. For most applications, setting CFAGS=-m64 LDFLAGS=-m64 configure make works. However, one or two applications don't work well. In
Essentially, libtool needs to know about gcc's specs, and what they do to a command-line. ISTM that using "-##" and the appropriate language-dependent driver should do most things that libtool needs,
If any of the Libtool users come and complain about libtool not linking against their old (or new) libraries after we've made the change, I want to be able to point to your documentation site and tel