], [ACTION-IF-FALSE])
basically works like 'AC_LINK_IFELSE' but redefines $ac_link such that
the linker is called via libtool.
Cheers,
Peter
___
https://lists.gnu.org/mailman/listinfo/libtool
+', so you need to change
them to underscore. We had something like this is our 'Makefile.am'
before we changed name on the project.
lib_LTLIBRARIES = libc++_tools.la
libc___tools_la_SOURCES =
hth,
Peter
___
https://lists.gnu.org/mailman/listinfo/libtool
unc_append dir "$objdir"
>
> if test -n "$relink_command"; then
> + # Strip any trailing slash from the destination.
> + func_stripname '' '/' "$libdir"
> + destlibdir=$func_stripname_result
> +
> + func_str
On 2016-02-12 21:59, Vadim Zeitlin wrote:
> Peter Rosin writes:
>> On 2016-02-11 00:38, Bob Friesenhahn wrote:
>>> It indicates that the build configuration has agreed to supply any
>>> additional dependency libraries if there otherwise would be undefined
>>&g
t cause strange bugs. Or if different DLLs
link to the same static malloc library and that that in turn produces
multiple heaps causing pain should pointers be passed across the DLL
boundaries.
If libtool should be in the business of protecting from such disasters
is another matt
On 2016-02-11 12:23, Evgeny Grin wrote:
> On 11.02.2016 11:03, Peter Rosin wrote:
>> Well said, I would also like to add that libtool -no-undefined *does* *not*
>> imply ld --no-undefined. I.e. If you add libtool -no-undefined, then the
>> *only* thing that changes is
can handle that, then that will continue to work.
Conditionally adding -no-undefined for systems where it matters is overly
defensive.
Repeat after me:
libtool -no-undefined is not at all the same thing as ld --no-undefined.
Cheers,
Peter
___
https://lists.gnu.org/mailman/listinfo/libtool
verything to produce something,
> whatever it is. It might indeed be sufficient if you're just compiling
> "Hello world" for MSW and are happy to get whatever you get with the
> minimal amount of effort, but it's just not go
toolchain, you still
use a mingw* host-triplet, why you you want to wander away from
that when you use the mingw toolchain from msys2? So, the patch is
suspect even if my above assumption is correct.
Cheers,
Peter
___
https://lists.gnu.org/mailman/listinfo/libtool
On 2015-07-24 23:32, Greg Jung wrote:
> On Fri, Jul 24, 2015 at 2:03 PM, Peter Rosin <mailto:p...@lysator.liu.se>> wrote:
>>
>> [ mingw-users: this is in reply to a suggested patch (1) ]
>>
>> On 2015-07-23 19:30, fabrizio...@tiscali.it
>
building binaries with the cygwin/posix emulation layer, but
you are adding msys to a bunch of places which are mingw-only.
So, it all feels fishy.
Also, how does this affect msys1?
Cheers,
Peter
(1) http://lists.gnu.org/archive/html/libtool/2015-07/msg3.html
___
#Static-libraries
Cheers
Peter
--
Peter Johansson
___
https://lists.gnu.org/mailman/listinfo/libtool
early as
possible. With this change, there are a lot of functions to parse
before getting to func_compile (and all of them are not needed that
early in the script, I think, but I have not verified that). Maybe
that can explain the difference? You could try to manually move
functions that are not needed by func_compile to appear after
func_compile and see if that makes a difference.
Cheers,
Peter
___
https://lists.gnu.org/mailman/listinfo/libtool
On 2015-02-06 10:30, Gary V. Vaughan wrote:
> Hi Peter,
>
>> On Feb 6, 2015, at 9:22 AM, Peter Rosin wrote:
>>
>>> On 2015-02-04 15:48, Bob Friesenhahn wrote:
>>>> On Wed, 4 Feb 2015, Robert Yang wrote:
>>>>
>>>> When reporting a bu
ltmain.sh->libtool step. But how to get to the relevant
automake version? If automake is even used for the package in
question...
Cheers,
Peter
___
https://lists.gnu.org/mailman/listinfo/libtool
On 02/06/2015 02:12 PM, Bob Friesenhahn wrote:
It is curious that there is more impact for the optimized builds.
Well, it's a constant 5s impact for both optimized and non-optimized -
except for v2.4.3 which looks odd.
Cheers,
--
Peter Joha
On 2015-01-20 18:24, Gary V. Vaughan wrote:
> -# Copyright (C) 2010-2015 Free Software Foundation, Inc.
> +# Copyright (C) 2010-2014 Free Software Foundation, Inc.
That's why I felt so young today!
Cheers,
Peter
___
https://lists.gnu.
ose or potential side-effects of the first patch.
>> | If you could provide those, I'll certainly make the time to
>> | evaluate, and maybe apply if all is well...
>> |
>> | Cheers,
>>
>> Missed your message somehow. Sorry.
>
> No problem, we still have abo
do this, it assumes that the application will have
some means to find the module, and will therefore not install it
somewhere else (such as in /usr/lib/../bin instead of in /usr/lib).
Suggested reading: "Dlopened modules" in the manual.
http://www.gnu.org/software
de in question can be found here
>> http://git.savannah.gnu.org/cgit/guile-ncurses.git/tree/ncurses/Makefile.am
>>
>> Any ideas?
>
> autoreconf -ifv
> before conf and make
>
> just to be sure the cygwin libtool is used
While a good recommendation in general, it will not help with this issue. There
are no patches in the Cygwin Libtool package that are relevant to the observed
behaviour.
Cheers,
Peter
___
https://lists.gnu.org/mailman/listinfo/libtool
rses.la
> libtool: install: warning: remember to run `libtool --finish /usr/local/lib'
>
>
> The makefile for the code in question can be found here
> http://git.savannah.gnu.org/cgit/guile-ncurses.git/tree/ncurses/Makefile.am
>
> Any ideas?
My guess is that libguil
tapes lately? From your development
(or build) system? Another workaround would be to uninstall the magnetic
tape control program.
But sure, Libtool could open code it and redo what AC_CHECK_TOOL does
but with the mt-check integrated in the path search loop. Hmm, using
AC_PATH_PROGS_FEATURE_CHECK might be viable? Patches are welcome, I
suppose.
Cheers,
Peter
___
https://lists.gnu.org/mailman/listinfo/libtool
re MANIFEST_TOOL=:
should also do it. Caveat emptor, I haven't actually tested any of the above...
> Please copy me on any answers, as I am not subscribed to this list.
Cheers,
Peter
___
https://lists.gnu.org/mailman/listinfo/libtool
On 2014-09-05 17:19, raz...@eml.cc wrote:
> On Fri, Sep 05, 2014 at 05:05:52PM +0200, Peter Rosin wrote:
>> On 2014-09-05 16:52, raz...@eml.cc wrote:
>>> Hi Peter, thank you
>>>
>>> attacched the zzip config.log.
>>
>> Bleh, sorry, but could you a
On 2014-09-05 16:52, raz...@eml.cc wrote:
> Hi Peter, thank you
>
> attacched the zzip config.log.
Bleh, sorry, but could you also provide the output from
./libtool --config
from your build directory?
Cheers,
Peter
'libzzip.la' failed
You seem to have configured libzzip in such a way that it thinks it is
should be built with Microsoft tools. That may not be your fault, but
can we see the config.log file please?
The "undefined symbols" warning suggests th
On 05/26/2014 05:07 PM, Peter Johansson wrote:
Hm, there is nothing in my 'Makefile.in' that mentions --mode=finish.
Is there any reason for that or is it a automake bug?
I investigated this a bit further. 'libtool --mode=finish' is indeed
called and it calls 'ldconf
r)'"; \
$(MKDIR_P) "$(DESTDIR)$(libdir)" || exit 1; \
echo " $(LIBTOOL) $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS)
--mode=install $(INSTALL) $(INSTALL_STRIP_FLAG) $$list2
'$(DESTDIR)$(libdir)'"; \
$(LIBTOOL) $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=i
27;/etc/ld.so.conf.d/local.conf' that contains '/usr/local/lib' to make
the runtime linker aware of '/usr/local/lib'. Yet I need to do a
ldconfig manually every time I install something. Am I missing something
or doing something wrong? This is on RHEL
p these -f? I could not find any instruction
> about this in the documentation.
>
> Thanks for reading (the English parts of this message :)!
This last part is an FAQ:
http://www.gnu.org/software/libtool/manual/libtool.html#FAQ
Cheers,
Peter
___
https://lists.gnu.org/mailman/listinfo/libtool
inker works not
> as configure expect.
> I suggest to pass all flags to linker, as in compile mode.
This is an FAQ:
http://www.gnu.org/software/libtool/manual/libtool.html#FAQ
Cheers,
Peter
___
https://lists.gnu.org/mailman/listinfo/libtool
Update of sr #108558 (project libtool):
Status:None => Done
___
Follow-up Comment #10:
Patch pushed.
Cheers,
Pe
On 2014-05-06 15:30, Peter Rosin wrote:
> Follow-up Comment #8, sr #108558 (project libtool):
>
> I have attached a patch that does the safe-safe-safe version.
> Does it work for you?
*snip*
> <http://savannah.gnu.org/support/?108558>
To not force everyone to follow
Follow-up Comment #8, sr #108558 (project libtool):
I have attached a patch that does the safe-safe-safe version.
Does it work for you?
Cheers,
Peter
(file #31318)
___
Additional Item Attachment:
File name: 0001-libtool-fix-nm-test-for
Update of sr #107959 (project libtool):
Status:None => Done
___
Follow-up Comment #1:
Fixed a while ago by commit a5a4944fbb2bbd20adb12b.
Cheers,
Pe
n only does the above on MSYS...
Crap again.
Cheers,
Peter
___
Reply to this item at:
<http://savannah.gnu.org/support/?108558>
___
Meddelandet skickades via/av Savannah
ht
uture MSYS stripping one
leading slash as it currently does for command line switches?
Then again, accidentally (or otherwise) creating an empty
C:\dev\null file does not seem totally unlikely, so maybe
using dev/null isn't so bright after all...
Crap.
Che
Update of sr #108559 (project libtool):
Status:None => Done
___
Follow-up Comment #3:
I have now pushed this change, thanks for testing!
Cheers,
Pe
e externally_visible volatile
+#else
+# define externally_visible __attribute__((externally_visible)) volatile
+#endif
+externally_visible const char * MAGIC_EXE = "$magic_exe";
Does the above work for you?
Cheers,
Peter
_
haven't used it for some time.
That would also work on MSYS1.
However, I had an idea. Anyone against using
"$tmp_nm" -B ///dev/null
everywhere? "///foo" and "/foo" should be equivalent according to
Posix. We should stil
cit
NM=... The alternative is for libtool use some other non-existant
or otherwise special file on MSYS, when it is trying to work out
if nm supports -B. I don't know what that file would be though,
and it always feels a little bit icky to special case things.
Cheers,
Peter
_
On 2014-04-29 17:30, Evgeny Grin wrote:
> 29.04.2014, 11:36, "Peter Rosin":
>>>> The situation you outlined is due to a defective package
>>>> preparation/build environment. A proper build has just one version of
>>>> a given library in a link
til
> you signal that you aware of something?
Because the current behavior results in a working library in more cases?
Because it breaks projects depending on current behavior?
Or are you mainly referring to your desire to link static libs into a
shared lib? In that case, perhaps
or file names in the directory `unfat-$$'. However, if
>> the value of `foo_LIBADD' contains a subdirectory, as in
>>
>> libharfbuzz_la_LIBADD = hb-ucdn/libhb-ucdn.la
>>
>> this fails, since `$darwin_file' now contains something with slashes.
&
On 2013-12-09 04:37, Gary V. Vaughan wrote:
> On Dec 9, 2013, at 11:52 AM, Peter Rosin wrote:
>> ok to push?
>
> Just to reiterate: I found the barrier for contributing to libtool had
> become insanely high in years past, to the point where even I found it
> hard to motiva
On 2013-12-07 08:53, Gary V. Vaughan wrote:
> On 6 Dec 2013, at 21:11, Peter Rosin wrote:
>> In my setup, I have to rerun "./bootstrap -fc" after every commit I make
>> to my local git libtool repo, which is very annoying. I
>>
>> inline-source: error:
[dropping libtool-patches@]
On 2013-11-12 12:24, Peter Rosin wrote:
> [re-adding libtool@]
>
> On 2013-11-11 16:10, Bob Friesenhahn wrote:
>> On Mon, 11 Nov 2013, Peter Rosin wrote:
>>>>>
>>>>> Quite a lot of effort went into making this work the wa
libtoolize
GEN public-submodule-commit
Is it expected that I need to manually rerun bootstrap after every commit?
Cheers,
Peter
___
https://lists.gnu.org/mailman/listinfo/libtool
On 2013-11-20 00:32, Gary V. Vaughan wrote:
> Hi Ozkan, Petor,
>
> On Nov 19, 2013, at 11:57 PM, Peter Rosin wrote:
>
>> On 2013-11-19 10:08, Ozkan Sezer wrote:
>>>> Starting with fec7d87 ("funclib.sh: simplify version comparison
>>>> functions&qu
e.
I came up with this patch, but I don't know how portable it is, so I would
like someone knowledgeable to comment on it before pushing it...
Cheers,
Peter
>From a7462c5563e124e06f4f61ce2a9cea26cf8be390 Mon Sep 17 00:00:00 2001
From: Peter Rosin
Date: Tue, 19 Nov 2013 11:54:27 +0100
Sub
[re-adding libtool@]
On 2013-11-11 16:10, Bob Friesenhahn wrote:
> On Mon, 11 Nov 2013, Peter Rosin wrote:
>>>>
>>>> Quite a lot of effort went into making this work the way it currently does.
>>
>> I realize that, but if it really works or not is a differe
incompatible change? Or simply a bug
fix?
BTW, it even appears to work, but please test, as I have only
done very light testing...
Oh well. Any thoughts?
Cheers,
Peter
>From a233b4562d4274053852bc0353e36931beeb4803 Mon Sep 17 00:00:00 2001
From: Peter Rosin
Date: Fri, 8 Nov 2013 19:01:2
On 2013-11-08 14:15, Peter Rosin wrote:
> On 2013-11-08 12:18, Panicz Maciej Godek wrote:
>> 2013/11/8 Peter Rosin mailto:p...@lysator.liu.se>>
>>
>> The SDL library, for some obscure reason, has its own special take on
>> that and
>> prescribes th
On 2013-11-08 12:18, Panicz Maciej Godek wrote:
> 2013/11/8 Peter Rosin mailto:p...@lysator.liu.se>>
>
> The SDL library, for some obscure reason, has its own special take on
> that and
> prescribes that you should keep using main() even if you are doing a GUI
>
DL_main (see that -Dmain=SDL_main define above). Some part of this
fragile SDL crap fails. I don't know what.
Perhaps the SDL_main library was compiled to expect an ordinary main entry
point instead of the GUI WinMain@16 version?
Just to be clear, I'm no
I'm at a loss then. But I bet it's some kind of argument ordering issue...
Maybe you could try moving -mwindows last or something?
How to make that happen sanely with pkg-config is another matter. Sigh.
Cheers,
Peter
___
https://lists.gnu.org/mailman/listinfo/libtool
case the specifics are that you are adding a lot of $(FOO_LIBS) vars to
AM_LDFLAGS in src/Makefile.am when you should probably have specified
them in slayer_LDADD or something such instead.
Hope that helps.
Cheers,
Peter
___
https://lists.gnu.org/mailman/listinfo/libtool
"new" application. When you remove support
for interface 0, you make an incompatible change which gets you from
"interface 1, age 1" to "interface 2, ago 0". I.e. "interface 1, age 0"
is not a valid successor to "interface 1, age 1".
Cheers,
Peter
___
https://lists.gnu.org/mailman/listinfo/libtool
On 2013-09-17 10:23, Peter Rosin wrote:
> On 2013-09-17 09:50, Ozkan Sezer wrote:
>> Any chance that this patch, or a patch that fixes bug #15321 [1],
>> gets applied any time?
>
> Yes, I'll push it in a bit.
Pushed.
Cheers,
Peter
___
hortly without review.
Thanks for your patience.
Cheers,
Peter
___
https://lists.gnu.org/mailman/listinfo/libtool
On 2013-09-10 16:10, Peter Rosin wrote:
> On 2013-09-10 15:56, Ozkan Sezer wrote:
>> OK then, I'll keep an eye on mails from this list.
>>
>> (On an irrelevant note, the archive pages at
>> http://lists.gnu.org/archive/html/libtool/2013-09/index.html
>>
ne have
arrived through the list. Maybe they are stuck in moderation, but
I don't know the details of that???
Anyway, I managed to dig up at least some background, see this thread
http://lists.gnu.org/archive/html/bug-libtool/2006-09/msg00019.html
Cheers,
Peter
On 2013-09-10 15:29, Ozkan Sezer wrote:
> On 9/10/13, Peter Rosin wrote:
>> On 2013-09-10 15:00, Ozkan Sezer wrote:
>>> On 9/10/13, Peter Rosin wrote:
>>>> On 2013-09-10 12:52, Ozkan Sezer wrote:
>>>>> That effectively cripples libtool for cross
On 2013-09-10 15:00, Ozkan Sezer wrote:
> On 9/10/13, Peter Rosin wrote:
>> On 2013-09-10 12:52, Ozkan Sezer wrote:
>>> That effectively cripples libtool for cross-compilers. Can the behavior
>>> be refined instead? Can you contact Charles Wilson about this?
>>
On 2013-09-10 12:52, Ozkan Sezer wrote:
> That effectively cripples libtool for cross-compilers. Can the behavior
> be refined instead? Can you contact Charles Wilson about this?
He should be reading this list, if he has time...
Anyway, does this work?
Cheers,
Peter
diff --git a/m4/libt
On 2013-09-10 12:25, Ozkan Sezer wrote:
> On 9/10/13, Ozkan Sezer wrote:
>> On 9/10/13, Peter Rosin wrote:
>>> On 2013-09-10 11:26, Ozkan Sezer wrote:
>>>> On 9/10/13, Peter Rosin wrote:
>>>>> On 2013-09-10 10:55, Ozkan Sezer wrote:
>>>>
On 2013-09-10 11:50, Ozkan Sezer wrote:
> On 9/10/13, Peter Rosin wrote:
>> On 2013-09-10 11:26, Ozkan Sezer wrote:
>>> On 9/10/13, Peter Rosin wrote:
>>>> On 2013-09-10 10:55, Ozkan Sezer wrote:
>>>>> On 9/10/13, Peter Rosin wrote:
>>>>&
On 2013-09-10 11:26, Ozkan Sezer wrote:
> On 9/10/13, Peter Rosin wrote:
>> On 2013-09-10 10:55, Ozkan Sezer wrote:
>>> On 9/10/13, Peter Rosin wrote:
>>>> On 2013-09-10 09:47, Ozkan Sezer wrote:
>>>>> On 9/10/13, Peter Rosin wrote:
>>>>&
On 2013-09-10 10:55, Ozkan Sezer wrote:
> On 9/10/13, Peter Rosin wrote:
>> On 2013-09-10 09:47, Ozkan Sezer wrote:
>>> On 9/10/13, Peter Rosin wrote:
>>>> On 2013-09-10 09:08, Ozkan Sezer wrote:
>>>>> Tell me if you need anything else.
>>&
On 2013-09-10 09:47, Ozkan Sezer wrote:
> On 9/10/13, Peter Rosin wrote:
>> On 2013-09-10 09:08, Ozkan Sezer wrote:
>>> Tell me if you need anything else.
>>
>> Let's focus on the libtool 2.4.2.393-5d4a if that's ok with
>> you.
>>
>&
On 2013-09-10 09:08, Ozkan Sezer wrote:
> Tell me if you need anything else.
Let's focus on the libtool 2.4.2.393-5d4a if that's ok with
you.
Can you provide the output from "libtool --config" and
config.log? I'm not set up to easily duplicate your
e
ew libtools (since 2.4) do in fact make
use of dlltool --identify when available, and I do not have any problem
handling -lole32 -ldsound -lwinmm when I try. We need more context to
help.
Wild guess, could it be a missing -L /lib/w32api at play?
Cheers,
Peter
___
https://lists.gnu.org/mailman/listinfo/libtool
r to me...
Given all the pain the "avoid cross-compile mode at all costs" mentality
is causing, it would be really nice if autotools could be taught (or told
how) to run run-time checks even in cross-compile mode, whenever that is
possible to do as
On 2013-08-22 10:20, Gary V. Vaughan wrote:
> Hi Peter,
>
> On Aug 22, 2013, at 2:54 PM, Peter Rosin wrote:
>
>> On 2013-08-22 09:40, Gary V. Vaughan wrote:
>>>> Can we please get this simple patch pushed?
>>>
>>> Done.
>>
>> To me
On 2013-08-22 09:40, Gary V. Vaughan wrote:
>> Can we please get this simple patch pushed?
>
> Done.
To me, it appears as if what you actually pushed was not what was posted?
Cheers,
Peter
___
https://lists.gnu.org/mailman/listinfo/libtool
ax. Anyone
with an idea?
Thanks,
Peter
___
https://lists.gnu.org/mailman/listinfo/libtool
On 07/18/2013 01:59 PM, Dennis Clarke wrote:
from the source tarball .. here is try number five :
mimas$ sx ../src/libtool-2.4.2.tar.gz
star: 1165 blocks + 0 bytes (total of 11929600 bytes = 11650.00k).
mimas$ mv libtool-2.4.2 libtool-2.4.2_SunOS5.8_sparcv9.005
mimas$ cd libtool-2.4.2_SunOS5.8_
Grab them from
any GNU archive site.
This rule to generate 'aclocal.m4' should not be triggered when building
from configure. Looks like you have touched some file.
Cheers,
Peter
___
https://lists.gnu.org/mailman/listinfo/libtool
On 2013-04-26 23:48, Peter Rosin wrote:
> On 2013-04-26 18:51, NightStrike wrote:
>> On Fri, Apr 26, 2013 at 4:06 AM, Peter Rosin wrote:
>>> You had LD=i686-w64-mingw32-gcc, which will not make libtool happy. You
>>> might try LD=i686-w64-mingw32-ld instead, but you sh
On 2013-04-26 18:51, NightStrike wrote:
> On Fri, Apr 26, 2013 at 4:06 AM, Peter Rosin wrote:
>> On 2013-04-26 13:58, NightStrike wrote:
>>> On Wed, Apr 24, 2013 at 8:52 PM, Peter Rosin wrote:
>>>> On 2013-04-24 22:24, NightStrike wrote:
>>>>>
On 2013-04-26 13:58, NightStrike wrote:
> On Wed, Apr 24, 2013 at 8:52 PM, Peter Rosin wrote:
>> On 2013-04-24 22:24, NightStrike wrote:
>>> On Wed, Apr 24, 2013 at 4:16 PM, NightStrike wrote:
>>>> On Wed, Apr 24, 2013 at 4:01 PM, Peter Rosin wrote:
>>>>
On 2013-04-24 22:24, NightStrike wrote:
> On Wed, Apr 24, 2013 at 4:16 PM, NightStrike wrote:
>> On Wed, Apr 24, 2013 at 4:01 PM, Peter Rosin wrote:
>>> So, it appears that LT_PATH_LD does not like your ld? I'd look into
>>> that.
>>
>> Where is the a
On 2013-04-24 18:29, NightStrike wrote:
> On Wed, Apr 24, 2013 at 12:17 PM, NightStrike wrote:
>> On Wed, Apr 24, 2013 at 11:55 AM, NightStrike wrote:
>>> On Wed, Apr 24, 2013 at 2:47 AM, Peter Rosin wrote:
>>>> On 2013-04-23 16:12, NightStrike wrote:
>>
quot; | $SED '\''s/ -lc$//'\''` -link -dll~linknames='
# The linker will automatically build a .lib file if we build a DLL.
_LT_TAGVAR(old_archive_from_new_cmds, $1)='true'
# FIXME: Should let the user specify the lib program.
_LT_T
ault seems
problematic, or are there strong reasons to prefer default in the
general case?
Cheers,
Peter
case $host_os in
rhapsody* | darwin1.[[012]])
_lt_dar_allow_undefined='${wl}-undefined ${wl}suppress' ;;
darwin1.*)
_lt_dar_allow_undefined='${wl}-flat_
chive
../foo/libfoo.a -Wl,-no-whole-archive
/usr/bin/ld: unknown flag: -no-whole-archive
Cheers,
Peter
--
Peter Johansson
___
https://lists.gnu.org/mailman/listinfo/libtool
z] Error 1
Cheers,
Peter
___
https://lists.gnu.org/mailman/listinfo/libtool
o the executable and executable fails at runtime.
Cheers,
Peter
___
https://lists.gnu.org/mailman/listinfo/libtool
line 147: 80434 Trace/BPT trap: 5 ./baz
Has anyone seen anything like this? Is this a bug in the apple linker or
are we using libtool incorrectly? I found this old thread from Peter
O'Gorman
http://lists.gnu.org/archive/html/libtool-patches/2007-02/msg00063.html
but not sure how to
On 2013-01-28 17:33, Jan Engelhardt wrote:
> On Monday 2013-01-28 17:18, Peter Rosin wrote:
>> On 2013-01-28 14:07, Jan Engelhardt wrote:
>>> @@ -1696,7 +1696,7 @@ not
>>> libdir='/tmp/usr/local/lib'
>>> @end example
>>>
>>>
> against the libraries in @var{inst-prefix-dir}/@code{prefix},
> not @code{prefix}.
>
Hi Jan,
Thanks for the patch!
I have pushed it with a proper commit message, would you like me to
update your email address in THANKS?
Cheers,
Peter
___
https://lists.gnu.org/mailman/listinfo/libtool
On 2013-01-18 17:32, Peter Rosin wrote:
> On 2013-01-01 19:03, Gary V. Vaughan wrote:
>> maint: remove unsupported Tested-by: tag.
>>
>> * build-aux/git-log-fix: Tested-by: line should not appear in the
>> ChangeLog.
>>
>> Signe
7;m perfectly fine with Libtool not
wanting Tested-by: tags, I fail to see how they can be
"unsupported".
So, I'm just curious about what damage it was causing? Is it just
that the git origin of the ChangeLog shows, or something more
tangible?
Cheers,
Peter
___
s on CentOS6 and with libtool 2.4.2.
Thanks,
Peter
___
https://lists.gnu.org/mailman/listinfo/libtool
,
Peter
___
Reply to this item at:
<http://savannah.gnu.org/support/?108201>
___
Message sent via/by Savannah
http://savannah.gnu.org/
___
real change hostage to the testsuite work
might just be enough the get the remaining kinks hammered
out. >;-) But then again, maybe we should simply punt
and not test the SONAME at all, given that it seems non-
trivial to know when the check should actually run? Anybody
else with an op
little Solaris expertise and will therefore
leave the resolution of the issue to someone more capable.
All in all, it's the Solaris part/port of libtool that is
buggy, and -no-undefined should stay in LDFLAGS in all those
test cases.
Cheers,
Follow-up Comment #18, sr #108201 (project libtool):
I believe gcc 4.5.3 is the latest stable for Cygwin. I do not
trust myself to be able to build a new gcc and verify that it
actually works for Cygwin without investing far more time than I
think is warranted. I imagine that there is some good re
Follow-up Comment #16, sr #108201 (project libtool):
I had an old git checkout from some time back (with some totally
unrelated work in it) and I used that to run the export test.
I'm not wasting hours on a full testsuite runs for this.
I tested once configuring with CC=g++ and once with CC=gcc. B
lid check. You (or
someone) need to find some criteria for when the new check is
sure to be valid, and skip past it otherwise.
SONAME is ELF-specific. Not everything is ELF.
Cheers,
Peter
___
Reply to this item at:
<h
1 - 100 of 679 matches
Mail list logo
