This is an automated email from the git hooks/post-receive script.
vapier pushed a commit to branch master
in repository libtool.
The following commit(s) were added to refs/heads/master by this push:
new 5a7193db libtool: remove bitrig support.
5a7193db is described below
commit
This is an automated email from the git hooks/post-receive script.
ildumi pushed a commit to branch master
in repository libtool.
The following commit(s) were added to refs/heads/master by this push:
new 81e8abf3 libtool: use -Fe with MSVC to specify filename
81e8abf3 is described below
Update of patch#10411 (group libtool):
Status:None => Done
Open/Closed:Open => Closed
___
Follow-up Comment #1:
Thanks for f
This is an automated email from the git hooks/post-receive script.
ildumi pushed a commit to branch master
in repository libtool.
The following commit(s) were added to refs/heads/master by this push:
new 4da5b575 libtool: fix empty "-L" in compiler_lib_search_path
4da5b575 is
The name of the system contains the string "nios2". This string
is caught by the some of the greedy checks for OS/2 in libtool,
in particular the *os2* branches of switch statements match for
the nios2 string, which results in incorrect behavior of libtool.
Switch to use $host_os instea
2)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iD8DBQFlppZFE9YstvghgroRAjFKAJ0fQTTh4qTJtgRvd/pI2TSeFIf4xgCeNEWF
mWoDIYiA2aMRvGaFs3ES9cE=
=fXIc
-END PGP SIGNATURE-
From 11d5ba83c5211ec7e149f3170bbaf7d49e6448da Mon Sep 17 00:00:00 2001
From: KO Myung-Hun
Date: Thu, 3 Nov 2022 23:32:37 +0900
Subj
libtool: remove bitrig support.
Bitrig has been defunct for 7 years.
* build-aux/ltmain.in (func_mode_link): Remove bitrig support.
* m4/libtool.m4 (_LT_CMD_OLD_ARCHIVE, LT_CMD_MAX_LEN)
(_LT_SYS_DYNAMIC_LINKER, _LT_CHECK_MAGIC_METHOD)
(_LT_LINKER_SHLIBS, _LT_LANG_CXX_CONFIG): Ditto.
* m4/ltdl.m4
there's a bunch of changes in here, but no additional test coverage
also the project still requires ChangeLog entries in the commit message,
so can you please add those so we don't have to write them for you ? if
you look at commit history, the format should hopefully be obvious.
-mike
On 25 Oct 2021 15:33, Richard Purdie wrote:
> The name of the system contains the string "nios2". This string
> is caught by the some of the greedy checks for OS/2 in libtool,
> in particular the *os2* branches of switch statements match for
> the nios2 string, which results
On 15 Jan 2024 21:15, KO Myung-Hun wrote:
> Mike Frysinger wrote:
> > On 15 Oct 2023 02:04, KO Myung-Hun wrote:
> >> Some OSes such as OS/2, uses ';' as a path separator. So using
> >> $PATH_SEPARATOR instead of hard-coded ':' is more proper.
> >>
> >> * build-aux-ltmain.in: replace : with
BQFlpSHTE9YstvghgroRAhS0AJoDOLC7CqgIxDOIjauhO3TW0TGvbACghk6m
pHAtNYl5XnpC4Pptph8j3sE=
=kxUR
-END PGP SIGNATURE-
From 23812414244882e7a7dbe790de648318643e66e6 Mon Sep 17 00:00:00 2001
From: KO Myung-Hun
Date: Thu, 3 Nov 2022 23:32:37 +0900
Subject: [PATCH v2] libtool: replace : with
On 15 Oct 2023 02:04, KO Myung-Hun wrote:
> Some OSes such as OS/2, uses ';' as a path separator. So using
> $PATH_SEPARATOR instead of hard-coded ':' is more proper.
>
> * build-aux-ltmain.in: replace : with $PATH_SEPARATOR.
> * m4/libtool.m4: Likewise.
this doesn't work for me
544675d6b538
but the size of the patch seems like it
> should require copyright papers. have you done those for the
> libtool project before ? -mike
Sure. I've done already.
- --
KO Myung-Hun
Korean OS/2 User Community : https://www.os2.kr/
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.7 (OS/2)
On 25 Oct 2021 15:33, Richard Purdie wrote:
> For reproducibilty, stop encoding the hostname into the libtool script, this
> isn't
> really adding much to debugging and most distros are carrying such a patch
> now as
> reproducibility is important.
thanks, merged
-mike
ld-aux/ltmain.in | 76 ++---
> m4/libtool.m4 | 16 +-
> 2 files changed, 46 insertions(+), 46 deletions(-)
this seems reasonable, but the size of the patch seems like it should require
copyright papers. have you done those for the lib
On 21 Dec 2022 17:36, Shinde, Yash wrote:
> https://lists.gnu.org/archive/html/libtool-patches/2011-01/msg00026.html
> Submission Date- Sun, 16 Jan 2011
> Upstream-Status: Submitted
>
> The given Libtool patch is with it’s current status as ‘Submitted’ but still
> is not tak
On 21 May 2023 20:28, Dmitry Antipov wrote:
> * build-aux/ltmain.in: Pass '-shared-libsan' and '-static-libsan'
> flags when linking.
>
> This is intented to link against shared and static sanitizer
> runtimes with Clang.
thx, merged now
-mike
signature.asc
Description: PGP signature
On 14 Sep 2022 00:10, jspri...@debian.org wrote:
> From: Jochen Sprickerhof
>
> grep 3.8 emits a warning for this.
thanks for the patch ... we merged fixed from Paul via
https://savannah.gnu.org/patch/index.php?10282
-mike
signature.asc
Description: PGP signature
Update of patch#10282 (group libtool):
Status:None => Done
Open/Closed:Open => Closed
___
Follow-up Comment #4:
merged both p
Update of patch#6691 (group libtool):
Status:None => Done
Open/Closed:Open => Closed
___
Follow-up Comment #4:
look
Hi all,
I am Ileana Dumitrescu, a new maintainer of libtool. To give some
background on myself, I have been contributing to Debian over the past
few years. Presently, I am a Debian Maintainer and the maintainer for
zvbi, which utilizes libtool.
To reference my application email:
"
Update of sr#110936 (group libtool):
Status:None => Done
Assigned to:None => vapier
Open/Closed:Open =&g
URL:
<https://savannah.gnu.org/support/?111002>
Summary: regression in libtool 2.4.7: build error in ncurses
Group: GNU Libtool
Submitter: None
Submitted: Sat 06 Jan 2024 07:54:04 AM UTC
Category
lgtm
-mike
signature.asc
Description: PGP signature
configure:
> >
> > ...
> > checking for arm-v7a-linux-gnueabihf-file... no
> > checking for file... file
> > configure: WARNING: using cross tools not prefixed with host triplet
> >
> > This was added in commit da2e35273572 ("libtool: replace som
Hello,
I got the Subject wrong, it must read:
libtool: Use AC_CHECK_PROG instead of AC_CHECK_TOOL to find "file"
(i.e. s/"find"/"file"/)
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König|
Industrial Linux Sol
prefixed with host triplet
>
> This was added in commit da2e35273572 ("libtool: replace some references
> to /usr/bin/file and /bin/sh") by using AC_CHECK_TOOL to find the file
> program (included in libtool 2.4.7).
>
> I wonder if using AC_CHECK_PROG would be more appropri
Additional Item Attachment, patch #10411 (project libtool):
File name: 0001-libtool-fix-empty-L-in-compiler_lib_search_path.patch Size:0
KB
<https://file.savannah.gnu.org/file/0001-libtool-fix-empty-L-in-compiler_lib_search_path.patch?file_id=55
URL:
<https://savannah.gnu.org/patch/?10411>
Summary: libtool: fix empty "-L" in compiler_lib_search_path
Group: GNU Libtool
Submitter: idings
Submitted: Mon 06 Nov 2023 08:48:30 AM UTC
da2e35273572 ("libtool: replace some references
to /usr/bin/file and /bin/sh") by using AC_CHECK_TOOL to find the file
program (included in libtool 2.4.7).
I wonder if using AC_CHECK_PROG would be more appropriate here. Or is it
really expected that file is installed as a cross tool using a ho
Some OSes such as OS/2, uses ';' as a path separator. So using
$PATH_SEPARATOR instead of hard-coded ':' is more proper.
* build-aux-ltmain.in: replace : with $PATH_SEPARATOR.
* m4/libtool.m4: Likewise.
---
build-aux/ltmain.in | 76 ++---
m4/libtool.m4
If a length of $release and/or $versionsuffix is more than 8 bytes,
a length of DLL name may be more than 8.
Then, this corrupts a generated DLL on OS/2.
* m4/libtool.m4 (soname_spec) [os2*]: Limit a length of DLL name to 8.3
correctly.
---
m4/libtool.m4 | 11 ---
1 file changed, 8
URL:
<https://savannah.gnu.org/support/?110936>
Summary: libtool webpage update
Group: GNU Libtool
Submitter: freddyz77
Submitted: Wed 27 Sep 2023 09:48:20 AM UTC
Category: None
Prior
URL:
<https://savannah.gnu.org/support/?110925>
Summary: libtool 2.4.7.4-1ec8f-dirty infinite loop on unknown
(out of order) argument
Group: GNU Libtool
Submitter: None
Submitted: Sun 20 Aug 2023 08:15:20
Follow-up Comment #3, sr #110901 (project libtool):
OK! Sorry for not investigating further, once I found the mailing list thread
that seemed like it terminated with the proper fix (and verifying it fixed it
for me) I stopped debugging the issue.
It is now clear. I think this relates
uilding is on Cygwin, not on MinGW.
--
Evgeny
On 25.06.2021 18:07, Dietmar May wrote:
SUMMARY
func_convert_core_msys_to_w32 in
/usr/share/libtool/build-aux/ltmain.sh
has an extraneous '/' in the call to
( cmd //c echo "$1" )
causing make to hang indefinitely
when configured with
--build=x8
Follow-up Comment #2, sr #110901 (project libtool):
[(Ошибка - не найдено)]
When starting any program under MSYS (and MSYS2), the MSYS[2] checks whether
the lunched program is linked with msys-*.dll.
If program is linked with this DLL then the program expects POSIX-like
environment so no path
Follow-up Comment #1, sr #110901 (project libtool):
[(Ошибка - не найдено)]
No, it's wrong.
See https://sourceware.org/pipermail/cygwin/2021-June/248814.html
___
Reply to this item at:
<https://savannah.gnu.org/support/?110
at install time, I don't see how tests can
reliably load the just-built library from the sources (objdir
really) rather than loading the installed library. Unless
perhaps there is a belief that LD_LIBARY_PATH is reliable and
supercedes, and there are wrappers
Yes, on all ELF systems, libtool creates
at install time, I don't see how tests can
reliably load the just-built library from the sources (objdir
really) rather than loading the installed library. Unless
perhaps there is a belief that LD_LIBARY_PATH is reliable and
supercedes, and there are wrappers
Yes, on all ELF systems, libtool creates
installed library. Unless
>>>>> perhaps there is a belief that LD_LIBARY_PATH is reliable and
>>>>> supercedes, and there are wrappers
>>>>
>>>> Yes, on all ELF systems, libtool creates wrappers that set
>>>> LD_LIBRARY_PATH, for all
URL:
<https://savannah.gnu.org/support/?110901>
Summary: libtool hangs indefinitely on windows when used in
msys due to cmd.exe call bug
Group: GNU Libtool
Submitter: mitchc
Submitted: Wed 19 Jul 2023 07:23:17
* build-aux/ltmain.in: Pass '-shared-libsan' and '-static-libsan'
flags when linking.
This is intented to link against shared and static sanitizer
runtimes with Clang.
Signed-off-by: Dmitry Antipov
---
build-aux/ltmain.in | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git
* build-aux/ltmain.in: Pass '-shared-libsan' flags when linking.
This is intented to link shared libraries against
sanitizer runtimes with Clang.
Signed-off-by: Dmitry Antipov
---
build-aux/ltmain.in | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/build-aux/ltmain.in
Good afternoon,
My name is Jennifer Robinson and I am a Supply Chain Risk Management Analyst at
NASA. NASA is currently conducting a supply chain assessment of GNU Libtool. We
are interested in confirming the following information:
1. Is there an organization which sponsors/publishes
From: Khem Raj
libstdc++ from gcc-runtime gets created with -rpath=/usr/lib/../lib for
qemux86-64
when running on am x86_64 build host.
This patch stops this speading to libdir in the libstdc++.la file within
libtool.
Arguably, it shouldn't be passing this into libtool in the first place
https://lists.gnu.org/archive/html/libtool-patches/2011-01/msg00026.html
Submission Date- Sun, 16 Jan 2011
Upstream-Status: Submitted
The given Libtool patch is with it’s current status as ‘Submitted’ but still is
not taken to the upstream. Please let us know about why the patch is not taken
On 2022-12-07, anonymous wrote:
[...]
> On an elderly Mac with PPC Mac OS X 10.4.11, Tiger, this was reported:
>
> expr: brackets ([ ]) not balanced
>
> It comes from this line
>
>76 year=`expr "$scriptversion" : '\([^-]*\)'`
>
> On two more up-to-date intel Macs expr worked correctly. I
URL:
<https://savannah.gnu.org/support/?110796>
Summary: libtool-2.4.7/build-aux/git-version-gen uses kind of
a hack
Project: GNU Libtool
Submitter: None
Submitted: Wed 07 Dec 2022 11:26:55 PM UTC
Category
Follow-up Comment #3, patch #10282 (project libtool):
[comment #2 comment #2:]
> Did you test to see if the new pattern still works with `grep` < 3.8 by any
chance?
Yes, it works.
> Just to check my understanding here: the intention of `[[-]]L` is to escape
`"[-]L"` in M
Follow-up Comment #2, patch #10282 (project libtool):
Thanks for the report and patch.
Did you test to see if the new pattern still works with `grep` < 3.8 by any
chance?
Just to check my understanding here: the intention of `[[-]]L` is to escape
`"[-]L"` in M4, taking advanta
Follow-up Comment #1, patch #10282 (project libtool):
This patch partly duplicates patch #10275, but it is more complete as it fixes
more instances of the problem. Sorry I did not notice this earlier. I do not
know how to merge the patch requests
URL:
<https://savannah.gnu.org/patch/?10282>
Summary: port libtool to grep 3.8 and to POSIX
Project: GNU Libtool
Submitter: eggert
Submitted: Mon 19 Sep 2022 01:27:13 PM PDT
Category: None
Pr
.deps/dibbler_client-DHCPClient.Pomv -f
.deps/dibbler_client-dibbler-client.Tpo
.deps/dibbler_client-dibbler-client.Po/bin/bash ./libtool --tag=CXX
--mode=link ccache
/usr/local/gcc-10.2-2020.11-aarch64/bin/aarch64-none-linux-gnu-g++
-lpthread -o dibbler-client dibbler_client-dibbler-client.o
From: Jochen Sprickerhof
grep 3.8 emits a warning for this.
---
m4/libtool.m4 | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/m4/libtool.m4 b/m4/libtool.m4
index 79a2451e..23d093ba 100644
--- a/m4/libtool.m4
+++ b/m4/libtool.m4
@@ -6442,7 +6442,7 @@ if test yes !=
Update of sr #110542 (project libtool):
Status:None => Done
Assigned to:None => growpotkin
Open/Closed:Open =&g
From: Marek Vasut
The name of the system contains the string "nios2". This string
is caught by the some of the greedy checks for OS/2 in libtool,
in particular the *os2* branches of switch statements match for
the nios2 string, which results in incorrect behavior of libtool.
This
From: Khem Raj
Libtool checks only for libraries linked as -l* when trying to
find internal compiler libraries. Clang, however uses the absolute
path to link its internal libraries e.g. compiler_rt. This patch
handles clang's statically linked libraries when finding internal
compiler libraries
From: Richard Purdie
For reproducibilty, stop encoding the hostname into the libtool script, this
isn't
really adding much to debugging and most distros are carrying such a patch now
as
reproducibility is important.
Signed-off-by: Richard Purdie
---
m4/libtool.m4 | 1 -
1 file changed, 1
<mailto:aixto...@felt.demon.nl>
Michael Felt
Mobile +31 (0)6 5184 4181
Email aixto...@felt.demon.nl
From: Libtool On Behalf Of
Alex Ameen
Sent: Sunday, 10 April 2022 21:47
To: libtool@gnu.org
Subject: Libtool Roadmap
Howdy, a few weeks ago I talked about s
bout things I like/dislike and want added based on my `libtool' usage over
> the years. However, I would be doing a disservice to users if I forced them
> to adopt "my way of using `libtool'" over their own. With that in mind it's
> important for y'all to share your own us
Howdy, a few weeks ago I talked about sending out a road-map.
I've gotten that prepared today. This roadmap is informal, opinionated,
and *I encourage feedback* and discussion on it. I have my own biases
and opinions about things I like/dislike and want added based on my
`libtool' usage over
aving more immediate
feedback where we can could make the tool much easier to extend.
On Thu, Mar 31, 2022, 9:24 PM Sam James wrote:
>
>
> > On 31 Mar 2022, at 21:42, Richard Purdie <
> richard.pur...@linuxfoundation.org> wrote:
> >
> > Hi,
> >
> On 31 Mar 2022, at 21:42, Richard Purdie
> wrote:
>
> Hi,
>
> It was great to see a libtool release, thanks for that!
>
> I upgraded Yocto Project to it in time for our LTS release:
>
> https://git.yoctoproject.org/poky/commit/?id=ff7b41573842a403c81f58
Hi,
It was great to see a libtool release, thanks for that!
I upgraded Yocto Project to it in time for our LTS release:
https://git.yoctoproject.org/poky/commit/?id=ff7b41573842a403c81f58bee41fc8163a9d7754
so far things seem reasonable, we've had a few minor issues but they're not
really
On 3/31/22 11:02, Jeff Squyres (jsquyres) wrote:
> Other than Bob's humorous reply, any comment from the Libtool team?
I'm also interested in any thoughts about the long term roadmap for libtool.
Like you, I think users can ask these questions out of a genuine interest to
align
downstr
Other than Bob's humorous reply, any comment from the Libtool team?
Thanks!
--
Jeff Squyres
jsquy...@cisco.com
From: Bob Friesenhahn
Sent: Friday, March 25, 2022 4:01 PM
To: Jeff Squyres (jsquyres)
Cc: libtool@gnu.org
Subject: Re: Libtool roadmap
On Fri, 25 Mar 2022, Jeff Squyres (jsquyres) wrote:
Congratulations on the Libtool 2.4.7 release!
(https://lists.gnu.org/archive/html/autotools-announce/2022-03/msg0.html)
Given that this is the first Libtool release in ~7 years, should we -- the
general developer community -- take
Congratulations on the Libtool 2.4.7 release!
(https://lists.gnu.org/archive/html/autotools-announce/2022-03/msg0.html)
Given that this is the first Libtool release in ~7 years, should we -- the
general developer community -- take this as an indication that the GNU Libtool
is back under
Hi Alex,
I look after the package currency for LibeELEC, and ran though testing
the latest libtool 2.4.7 release in LibreELEC.
a couple issues:
The tar.gz file has ltmain.sh as readonly. I fixed this in our build with the
workaround: chmod u+w ${PKG_BUILD}/build-aux/ltmain.sh (after unpack
Hi,
Xi Ruoyao wrote:
Hi libtool dev,
We've recently hit an issue cross-compiling some package using libtool
for sysroot. Saying libfoo.la contains
So there is a number of models . One to use system libtool and another one
libtool script builds for project.
First is not for cross-compilation
Hi libtool dev,
We've recently hit an issue cross-compiling some package using libtool
for sysroot. Saying libfoo.la contains
libdir=/usr/lib
Then libtool will add "-L/usr/lib" to the linker command line during a
"relink" against libfoo.la, because ltmain.in:650
-- Forwarded message -
من: Mohamed Atef
Date: الأربعاء، ٩ فبراير، ٢٠٢٢ ٤:٤٤ م
Subject: Libtool mismatch
To:
I am trying to add some files to libgomp But i get libtool mismatch error i
deleted aclocal.m4 and config.h.* files i still get the same error
Version mismatch error
On 2/8/22, Roumen Petrov wrote:
> As result is expected Debian to be flooded with defects.
>
>> Some of the outstanding bugs with existing patches :
>> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=38305
>> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=23348
>>
Ozkan Sezer wrote:
On 2/8/22, Julien ÉLIE wrote:
Hi Alex,
Feel free to reach out if you have pending patches/issues you want to
"bump", ideas for improvements, general advice for a new GNU maintainer
- and above all if you'd like to lend a hand toward getting `libtool' up
and run
On 2/8/22, Julien ÉLIE wrote:
> Hi Alex,
>
>> Feel free to reach out if you have pending patches/issues you want to
>> "bump", ideas for improvements, general advice for a new GNU maintainer
>> - and above all if you'd like to lend a hand toward getting `libtool'
Hi Alex,
Feel free to reach out if you have pending patches/issues you want to
"bump", ideas for improvements, general advice for a new GNU maintainer
- and above all if you'd like to lend a hand toward getting `libtool' up
and running again.
Many thanks for your work on Libtool!
Hi,
Following up on libtool bug 34076:
Patch to libtool for solaris 11.4 link-editor which rejects -pthread option
http://debbugs.gnu.org/cgi/bugreport.cgi?bug=34076
with this email to libtool-patches@gnu.org as documented on
https://www.gnu.org/software/libtool/contribute.html
FYI
essfully, but I want to skip the test suite. How to properly prevent the
invocation if winepath?
Using winepath in libtool really is an abomination and must be removed.
Related: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=52253
Using winepath is very useful to run regression tests in emulated e
On 2021-12-05 21:28:40 +0300, ilya Basin wrote:
> Dear List. I'm cross compiling a program on Linux for a mingw host
> and sometimes this shows Wine dialogs like "updating wine
> configuration" or "download and install Mono". I believe it's only
> needed to run `make check` successfully, but I
successfully, but I want to skip the test suite. How to properly prevent the
> invocation if winepath?
Using winepath in libtool really is an abomination and must be removed.
Related: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=52253
Dear List. I'm cross compiling a program on Linux for a mingw host and
sometimes this shows Wine dialogs like "updating wine configuration" or
"download and install Mono". I believe it's only needed to run `make check`
successfully, but I want to skip the test suite. How to properly prevent the
Update of patch #9996 (project libtool):
Status:None => Done
Assigned to:None => growpotkin
Open/Closed:Open =&g
it's hard to know which of them are still relevant - so I appreciate
> your help.
I did recently post the better bits of the OpenEmbedded/Yocto Project patchset
for libtool:
https://lists.gnu.org/archive/html/libtool-patches/2021-10/msg00012.html
Those are at up to date and in regula
on non-Linux, non-x86 platforms, we use the GCC
Compile farm project:
https://gcc.gnu.org/wiki/CompileFarm
I am certain they would be happy to give you access as Libtool maintainer.
Farm
I am certain they would be happy to give you access as Libtool maintainer.
--
Russ Allbery (ea...@eyrie.org) <https://www.eyrie.org/~eagle/>
wrote:
On 10/27/21, Alex Ameen wrote:
Howdy!
This is Alex Ameen reporting in from Austin, Texas. I'm a long time GNU
and `autotools' user who specializes in ELF linking and loading. I'm
writing you today to introduce myself and announce that I was recently
approved as the new maintainer of `libtool
the new maintainer of `libtool'!
>
> I'm excited to bring some updates to the tool and want to thank everyone
> for their patience while I work my through the pending patch/bug lists
> and get familiar with some of the maintenance infrastructure.
>
> In the near future I look fo
Update of patch #8977 (project libtool):
Status:None => Done
Open/Closed:Open => Closed
___
Reply to this item at:
announce that I was recently
> approved as the new maintainer of `libtool'!
>
> I'm excited to bring some updates to the tool and want to thank everyone
> for their patience while I work my through the pending patch/bug lists
> and get familiar with some of the maintenance infrastru
Howdy!
This is Alex Ameen reporting in from Austin, Texas. I'm a long time GNU
and `autotools' user who specializes in ELF linking and loading. I'm
writing you today to introduce myself and announce that I was recently
approved as the new maintainer of `libtool'!
I'm excited to bring some
From: Marek Vasut
The name of the system contains the string "nios2". This string
is caught by the some of the greedy checks for OS/2 in libtool,
in particular the *os2* branches of switch statements match for
the nios2 string, which results in incorrect behavior of libtool.
This
From: Khem Raj
Libtool checks only for libraries linked as -l* when trying to
find internal compiler libraries. Clang, however uses the absolute
path to link its internal libraries e.g. compiler_rt. This patch
handles clang's statically linked libraries when finding internal
compiler libraries
For reproducibilty, stop encoding the hostname into the libtool script, this
isn't
really adding much to debugging and most distros are carrying such a patch now
as
reproducibility is important.
Signed-off-by: Richard Purdie
---
m4/libtool.m4 | 1 -
1 file changed, 1 deletion(-)
diff --git
Hi,
I saw comments about a possible pending release and decided to take the
opportunity to send out the bulk of Yocto Project's patch queue
for libtool. We use it in a cross compiling environment and make
extensive use of the sysroot support in the toolchain so most of our
issues
Update of patch #8977 (project libtool):
Assigned to:None => growpotkin
___
Reply to this item at:
<https://savannah.gnu.org/patch
On Thursday, October 21, 2021 10:02:12 AM CEST Werner LEMBERG wrote:
>
> > A patch [4] was submitted to fix this [...]
I already contacted Jeremy (patch author) with the Copyright paperwork details.
> > Is there anything I can do to help this patch along?
>
> You might ste
I actually just submitted a PR for this issue that you can probably use.
savannah.gnu.org/patch/?10113
Hopefully this helps.
On Sun, Oct 17, 2021, 11:03 AM wrote:
> Send Libtool mailing list submissions to
> libtool@gnu.org
>
> To subscribe or unsubscribe via the World Wid
Wouldn't this patch break Solaris 11.3 and earlier?
On Mon, Sep 20, 2021 at 5:24 AM Stacey Marshall
wrote:
> URL:
> <https://savannah.gnu.org/support/?110542>
>
> Summary: Patch to libtool for solaris 11.4 link-editor
> which
>
URL:
<https://savannah.gnu.org/support/?110542>
Summary: Patch to libtool for solaris 11.4 link-editor which
rejects -pthread option
Project: GNU Libtool
Submitted by: staceym
Submitted on: Mon 20 Sep 2021 10:24:04
101 - 200 of 5840 matches
Mail list logo
