Alex,
can you estimate when you will be able to do a new release? Just to
tell people that the project is still alive :-)
Werner
> A patch [4] was submitted to fix this [...]
>
> Is there anything I can do to help this patch along?
You might step up as a new libtool maintainer, since Gary seems not to
have time any more for this project.
Werner
>>> Hello there! We have an autotools-based build system setup with a
>>> custom GCC where we take all build- and run-time dependencies
>>> (except for glibc) from /opt. [...]
>
> So far the cleanest hack I've found is to patch the generated
> "libtool" script so that the generated test wrappers
> Ulrich Drepper, in his article on DLLs
>
> https://www.akkadia.org/drepper/dsohowto.pdf
>
> (section 2.2.6), criticizes that libtool maps its `--export-symbols'
> option to GNU linker option `-retain-symbol-file'. Instead, it
> should use `-version-script'.
>
> This seems to be a valid con
Ulrich Drepper, in his article on DLLs
https://www.akkadia.org/drepper/dsohowto.pdf
(section 2.2.6), criticizes that libtool maps its `--export-symbols'
option to GNU linker option `-retain-symbol-file'. Instead, it should
use `-version-script'.
This seems to be a valid concern. Given that
Folks,
my ttfautohint library exports a single function (`TTF_autohint') and
depends on freetype and harfbuzz. A user posted the following recipe
to merge these three libraries into a single DLL in Windows.
- build all libraries statically
- create a `ttfautohint.def' file as below
- cal
Here's a bug report regarding the `join' program; a user trying to
compile the git version of FontForge also experienced this issue.
https://www.illumos.org/issues/6755
Maybe it makes sense to implement a work-around since Illumos is free
software.
Werner
___
Ping! I've updated to current git of libtool
(v2.4.2.444-28-g053df7e), and the problem persists.
I'll also contact the MinGW list.
BTW, does it make sense to send my original e-mail to bug-libtool?
Werner
==
> [libtoo
>> Indeed. However, how is that related to my request of having a
>> separate set of linker flags for *static* linking?
>
> Before libtool could adequately address such a feature, it would
> need to be supported by autoconf and configure scripts based on
> autoconf. If there are two sets of LDF
> Depending entirely on pkg-config is not wise since it is an add-on
> which is not part of the autotools framework and not uniformly
> maintained.
It is unrealistic to expect that all libraries needed by a package are
manually compiled by the user so that all `.la' files are present.
Additionall
Folks,
it seems it has been already discussed that libtool should use a
different set of link flags if compiling a static library, especially
for libraries that come without a corresponding `.la' file, cf. this
thread:
http://lists.gnu.org/archive/html/automake/2009-05/msg00068.html
Such a f
Some weeks ago I wrote:
> I've now found out that it *is* a libtool problem:
>
>> libtool: link: \
>> (cd
>> /Users/wl/harfbuzz-0.9.26/src/.libs/libharfbuzz.lax/libhb-ucdn.a/unfat-91266/libhb-ucdn.a-i386
>> \
>> && ar x "libhb-ucdn.a")
>> libtool: link: \
>> (cd
>> /Users/wl/h
I've now found out that it *is* a libtool problem:
> libtool: link: \
> (cd
> /Users/wl/harfbuzz-0.9.26/src/.libs/libharfbuzz.lax/libhb-ucdn.a/unfat-91266/libhb-ucdn.a-i386
> \
> && ar x "libhb-ucdn.a")
> libtool: link: \
> (cd
> /Users/wl/harfbuzz-0.9.26/src/.libs/libharfbuzz
[libtool 2.4.2]
I'm compiling harfbuzz under OS X 10.7.5 (i.e., Darwin 11.4.2), XCode
4.6.3 (i.e., i686-apple-darwin11-llvm-gcc-4.2 (GCC) 4.2.1), with the
following configuration flags; see attached build script for more.
--enable-static
LDFLAGS=CFLAGS=CXXFLAGS="-arch i386 -arch x86_64"
Do
Folks,
after configuring with libtool, I normally use
make LDFLAGS="-all-static"
to create binaries that are dependent on system libraries only. (Is
there a better way?) However, under OS X, frameworks are not
included. Instead, I have to explicitly write e.g.
make LDFLAGS="-all-static
[libtool 2.4.2]
Folks,
I have two programs, which I try to link with
make LDFLAGS=-all-static
to build stand-alone Windows binaries. One program has a command line
interface, and everything is just fine. The other one has a Qt GUI,
and suddenly there is a mysterious problem: The program u
This is a shy `ping' :-)
Werner
--
> [libtool 2.4.2]
>
> Folks,
>
>
> let's assume that someone is doing
>
> AC_SUBST([libdir])
> AC_SUBST([wl])
> AC_SUBST([hardcode_libdir_flag_spec])
>
> and later tries to s
[libtool 2.4.2]
Folks,
let's assume that someone is doing
AC_SUBST([libdir])
AC_SUBST([wl])
AC_SUBST([hardcode_libdir_flag_spec])
and later tries to say
libdir = @libdir@
wl = @wl@
hardcode_libdir_flag_spec = @hardcode_libdir_flag_spec@
within a Makefile, as can be done with oth
> I would therefore check in your configure script whether the *.la
> file you got from the --libtool option exists, and, if not, simply
> link directly with only the library you're using (-lfreetype, for
> instance) and assume everything will work.
OK.
> I would also encourage any library maint
>> Some foo-config scripts like freetype-config have an option
>>
>> --libtool
>>
>> to display the library's .la file. However, it is more and more
>> common that .la files get removed by distributions if installed in
>> /usr/lib, as you are certainly aware.
>
> What is this information used f
Some foo-config scripts like freetype-config have an option
--libtool
to display the library's .la file. However, it is more and more
common that .la files get removed by distributions if installed in
/usr/lib, as you are certainly aware.
My question is how to handle this properly. Shall th
> Looks like Qt's faked up .la files have -framework flags in
> dependency_libs, remove them and it might work.
Indeed, this did the trick, thanks! It now compiles fine. [It
doesn't run successfully, however, because the Qt stuff still needs
some extra files (in directory `qt_menu.nib'), but th
>> I get this link command together with the error message.
>>
>> /bin/sh ../libtool \
>>--tag=CXX \
>>--mode=link \
>>g++ -pipe -O2
>
> Please add a --debug after the ../libtool and send me the log of
> stderr and stdout.
Attached.
> There are no static versions of any of the system
[libtool 2.4.2]
Folks,
I have a problem with libtool on Mac OS X Lion, trying to link
statically to (a statically compiled version of) Qt. Saying
make LDFLAGS="-all-static" V=1
I get this link command together with the error message.
/bin/sh ../libtool \
--tag=CXX \
--mode=link \
g+
>>> I've found this interesting mail:
>>>
>>>http://lists.gnu.org/archive/html/libtool-patches/2011-08/msg0.html
>>>
>>> Interestingly, there was no comment at all. So my question: Is
>>> this the `right' approach? Will libtool provide something
>>> similar?
>
> I implemented something s
And another ping!
Werner
> I've found this interesting mail:
>
> http://lists.gnu.org/archive/html/libtool-patches/2011-08/msg0.html
>
> Interestingly, there was no comment at all. So my question: Is this
> the `right' approach? Will libtool provide something similar?
___
Ping! Is this really an unimportant issue?
Werner
> I've found this interesting mail:
>
> http://lists.gnu.org/archive/html/libtool-patches/2011-08/msg0.html
>
> Interestingly, there was no comment at all. So my question: Is this
> the `right' approach? Will libtool provide somet
I've found this interesting mail:
http://lists.gnu.org/archive/html/libtool-patches/2011-08/msg0.html
Interestingly, there was no comment at all. So my question: Is this
the `right' approach? Will libtool provide something similar?
Werner
__
> ftp://ftp.gnu.org/gnu/libtool/libtool-1.5.22.tar.gz
> ftp://ftp.gnu.org/gnu/libtool/libtool-1.5.22.tar.bz2
No .tar.bz2 bundle...
Werner
___
http://lists.gnu.org/mailman/listinfo/libtool
29 matches
Mail list logo
