On Mar 2, 2014, at 8:48 PM, Werner LEMBERG wrote:
>
> 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
[I replied to Werner without copying the list by mistake. Here is the
reply.]
On 03/23/2012 09:50 AM, Werner LEMBERG wrote:
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 ../libt
On 03/23/2012 06:40 AM, Christian Egli wrote:
libtool --mode=execute -dlopen ../liblouis/liblouis.la -n python $(TEST_SCRIPT)
What is the drawback of just setting LD_LIBRARY_PATH in
TESTS_ENVIRONMENT?
Not all systems use LD_LIBRARY_PATH. You can find the variable that
libtool sets by checkin
Hi,
On 03/23/2012 07:58 AM, Werner LEMBERG wrote:
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 \
--t
5d54d8ce Mon Sep 17 00:00:00 2001
From: Peter O'Gorman
Date: Fri, 16 Mar 2012 13:23:13 -0500
Subject: [PATCH] Fix typo that caused sys_lib_search_path_spec to be wrong.
* m4/libtool.m4: s/lt_fooi/lt_foo/.
Reported by Paul Seidler
---
m4/libtool.m4 |2 +-
1 files changed, 1 insertions(+)
Hi Paul,
On 03/12/2012 10:47 AM, Paul Seidler wrote:
Hello,
running the test suite of eina-1.1 with 1.0 installed and
libtool-2.4{.2,} the tests will fail (symbol lookup errors) because of
the LD_LIBRARY_PATH (same with glib, gst-plugins-base, ...). The libdir
is in front of the "test-path":
LD
n
Oak Ridge National Laboratory
On Dec 8, 2011, at 12:19 AM, Peter O'Gorman wrote:
On 12/05/2011 11:48 AM, Shamis, Pavel wrote:
Hi,
As have been mentioned on the list, libtool error reporting - "file not found" is not
perfect. People suggested to fix it (hxxp://www.mail-archiv
On 02/07/2012 07:06 PM, Lucas De Marchi wrote:
Yes. We can always learn. It seems that this is not the case here.
There are other projects releasing like this and no one pointed out to
a reasonable argument against it. That means these arguments are not
valid in our case:
Again, use -version-n
On 02/06/2012 06:35 PM, Jan Engelhardt wrote:
Much to my disappointment, I found that the newly-released libkmod v5
has made the following non-trivial change to its source tree, the latter
of which I want to bring to attention:
commit e479598b7d19ae7be45bf5329d6e4df32d646c16
diff
On 02/01/2012 05:49 PM, Bob Friesenhahn wrote:
The libltdl module loader does need to load the dependency libraries
since the system might not do this at all, or might not do it fully or
correctly. It can't do this without knowing the libraries used. This has
been known to be a definite factor f
On 01/09/2012 09:31 AM, Diab Jerius wrote:
make DESTDIR=/home/dj/stage prefix=/rbtree-1.0.9 exec_prefix=/rbtree-1.0.9/x86
install
The resultant file hierarchy is shallower:
/home/dj/stage
/home/dj/stage/rbtree-1.0.9
/home/dj/stage/rbtree-1.0.9/x86
/home/dj/stage/rbtree-1.0.9/x86/lib
/home/dj/
On 01/09/2012 08:50 AM, Diab Jerius wrote:
On Sat, 2012-01-07 at 13:31 -0600, Bob Friesenhahn wrote:
On Fri, 6 Jan 2012, Diab Jerius wrote:
and the installation is performed via
make AM_MAKEFLAGS="DESTDIR=/proj/axaf/simul/pkgs prefix=/lua_udunits2-0.1.2_01
exec_prefix=/lua_udunits2-0.1.2_01/
On 01/06/2012 12:31 PM, Peter O'Gorman wrote:
On 01/06/2012 11:21 AM, Stepan Kasal wrote:
1) .la file always contains the recursively evaluated list of libraries.
While this is necessary for static linking and dumb dynamic linkers,
it is an issue for dyn. linkers that can do recu
On 01/06/2012 11:21 AM, Stepan Kasal wrote:
1) .la file always contains the recursively evaluated list of libraries.
While this is necessary for static linking and dumb dynamic linkers,
it is an issue for dyn. linkers that can do recursive resolution
(which is the case on GNU/Linux distributions
Hi Max,
Thanks, I did as you suggested and removed future.html.
Peter
On 12/21/2011 10:30 AM, Max Horn wrote:
Hi Peter,
I tried two times now to send the following email to webmast...@www.gnu.org, but the address seems
to be dead and not accepting any delivery; after several days, each with
On 11/29/2011 11:48 PM, Adam Mercer wrote:
On Mon, Nov 28, 2011 at 23:30, Andy Spencer wrote:
This seems to be caused by libtool adding a -rpath flag which forces the
application to use the /usr/lib64 version provided by mesa even though
ld.so.conf has been properly configured to use the nvidi
On 12/05/2011 11:48 AM, Shamis, Pavel wrote:
Hi,
As have been mentioned on the list, libtool error reporting - "file not found" is not
perfect. People suggested to fix it (http://www.mail-archive.com/libtool@gnu.org/msg12156.html) but
it seems, that the changes have never been incorporated int
On 12/07/2011 11:45 AM, Mark R Bannister wrote:
Hi,
I wonder if someone could point out my error. I've defined a function,
nothing special, takes a couple of args and returns a pointer to a
structure.
The function is not declared with any special keywords. It is not static.
Yet, when compiled
Hi,
Looks like there was no daily snapshot for a couple of weeks because the
script was doing (the apparently naive):
git pull
./bootstrap
./configure
make
make distcheck
and the gnulib submodule never got updated, so bootstrap failed with:
top/README-release
top/maint.mk
2 out of 2 hunks
On 11/22/2011 11:36 PM, Adam Mercer wrote:
On Mon, Nov 21, 2011 at 15:39, Peter O'Gorman wrote:
Glad it works around it. The problem is libtool brokenness, most vendors
patch around it in their packaged libtool, e.g.
http://pkgs.fedoraproject.org/gitweb/?p=libtool.git;a=blob;f=libtool-2
On 11/21/2011 03:22 PM, Adam Mercer wrote:
Setting lt_cv_sys_lib_dlsearch_path_spec="/lib64 /usr/lib64" at
configure time results in "-Wl,-rpath -Wl,/usr/lib64" not being passed
and the correct libraries linked. So this is a workaround but I'd like
to understand why these flags are being added in
Hi,
On 11/19/2011 01:03 AM, Adam Mercer wrote:
Hi
In building a development snapshot of one of my projects, to a custom
path, on SL6 I am running into what appears to be a linking problem.
The libtool command used to link the library is as follows:
libtool: link: gcc -std=gnu99 -shared -fPIC
On 10/24/2011 01:54 PM, Peter O'Gorman wrote:
> On 10/24/2011 11:05 AM, Jason Self via RT wrote:
>> Hello libtool maintainers, just forwarding the above feedback to you for
>> your consideration. Perhaps one option might be linking to the GNU Emacs
>> manual instead of
On 10/24/2011 11:05 AM, Jason Self via RT wrote:
> Josh wrote:
>> Hi,
>>
>> I search the Emacs manual using Google's "site:" operator. For example:
>>
>> http://www.google.com/search?q=site:www.gnu.org/software/emacs+EXAMPLE
>>
>> I've been noticing that pages in the manual don't always show up in
On 10/24/2011 11:05 AM, Jason Self via RT wrote:
Josh wrote:
Hi,
I search the Emacs manual using Google's "site:" operator. For example:
http://www.google.com/search?q=site:www.gnu.org/software/emacs+EXAMPLE
I've been noticing that pages in the manual don't always show up in the
search result
On 10/17/2011 05:02 PM, Adam Mercer wrote:
On Mon, Oct 17, 2011 at 16:40, Peter O'Gorman wrote:
Peter
Does it work if you remove -mmacosx-version-min=10.4?
That resulted in the same error, but your idea led me to remove each
flag one by one and it turns out that the insane optimiz
On 10/17/2011 01:48 PM, Adam Mercer wrote:
Hi
I testing some software I maintain using the recently release
Xcode-4.2 on Mac OS X 10.7.2, and am running into the follow error
during link:
Hi,
Does it work if you remove -mmacosx-version-min=10.4?
Peter
/bin/sh ../../../libtool --tag=CC
On 10/14/2011 08:45 AM, David Aldrich wrote:
Hi Peter
Thanks for your reply.
-shared is not a libtool flag
Oh, that's weird! We've been using that option for building other shared
libraries for a long time.
Yes, and older libtools used to pass it along to the compiler driver, so
on system
On 10/14/2011 02:10 AM, David Aldrich wrote:
Hi
I am using libtool in a makefile to create a shared library containing my
application code, which also links to wxWidgets libraries. As a consequence of
changing both platform (including gcc version) and wxWidgets packages, my
makefile ceases t
On 06/14/2011 11:26 AM, Lasse Collin wrote:
On 2011-06-14 Bob Friesenhahn wrote:
On Tue, 14 Jun 2011, Lasse Collin wrote:
Please read the section "Understanding shared libraries
number rules" (it's short):
http://www.openbsd.org/faq/ports/specialtopics.html
If this web page text is corre
On 06/07/2011 08:07 PM, Michael Poole wrote:
Some of the files in my convenience libraries have static
initializers. By default, the linker discards these symbols because
they are not referenced. I am trying to figure out how to keep them
in an automake-driven build.
Mailing list threads I hav
On 04/27/2011 07:25 AM, Ed Hartnett wrote:
Howdy all!
Hi Ed,
Recently I managed to get my C library building and testing cleanly on
Linux for windows, using mingw32 and wine. This is the greatest idea
since sliced bread. (In fact, I would rather live without sliced bread!)
I am building i
On 01/31/2011 11:21 AM, Ed Hartnett wrote:
Peter O'Gorman writes:
/usr/bin/libtool: unknown option character `f' in: -force_load
Usage: /usr/bin/libtool -static [-] file [...] [-filelist
listfile[,dirname]] [-arch_only arch] [-sacLT]
Usage: /usr/bin/libtool -dynami
On 01/21/2011 08:19 AM, Michael Haubenwallner wrote:
Hello!
Hi.
Library versioning for AIX would be a great feature.
After playing around with different ways[1], this is my proposed one,
using an AIX feature called "Import Files":
*) Create the shared object "shr.o" (using '-G' linker flag
On 01/07/2011 06:30 AM, Ed Hartnett wrote:
libtool: link: g95 -dynamiclib -Wl,-undefined -Wl,dynamic_lookup -o
.libs/libnetcdff.0.dylib .libs/fort-attio.o .libs/fort-control.o
.libs/fort-dim.o .libs/fort-genatt.o .libs/fort-geninq.o
.libs/fort-genvar.o .libs/fort-lib.o .libs/fort
On 12/20/2010 10:54 AM, Bruce Korb wrote:
If the default build is 64 bit, why does it make sense that the
default library directory is the 32 bit library?
Because the user may not be building for multiple architectures, in
which case a default of $prefix/lib for libdir makes perfect sense an
On 12/17/2010 02:59 PM, Peter O'Gorman wrote:
On 12/17/2010 11:09 AM, Nelson H. F. Beebe wrote:
I normally do builds on the AMD64 platforms with something like this
(at a minimum):
env LDFLAGS='-L/usr/local/lib64 -Wl,-rpath,/usr/local/lib64' ./configure
make all check
make inst
On 12/17/2010 11:09 AM, Nelson H. F. Beebe wrote:
I normally do builds on the AMD64 platforms with something like this
(at a minimum):
env LDFLAGS='-L/usr/local/lib64 -Wl,-rpath,/usr/local/lib64' ./configure
make all check
make install libdir=/usr/local/lib64
It does no
On 12/06/2010 03:25 PM, Ralf Wildenhues wrote:
Where do you see that? As far as I understand, Paweł hasn't actually
tried configuring Libtool with something like
Yeah, I failed to read your entire email this morning, definitely didn't
have enough coffee. It makes sense now :)
We have some
On 12/06/2010 01:07 AM, Ralf Wildenhues wrote:
OK to apply?
Unless Pawel reports that it works for him, no. This doesn't make
sense to me.
Hi Ralf,
Why?
Well, perhaps I haven't been drinking enough coffee, but...
_LT_TAGVAR(lt_prog_compiler_wl, $1)='-Xlinker '
This assign
On 12/05/2010 09:34 PM, Ralf Wildenhues wrote:
Does this patch fix things for you? As far as I see, you should be
getting -fPIC passed instead of -fno-common, so it's not completely
clear that this is right, or what other changes MacPorts has done to
their glibtool code over upstream Libtool.
On 06/14/2010 04:41 PM, Peter O'Gorman wrote:
dlopen nonexisting file
dlopen existing file
check dlerror()
Ok, systems that return an error in this case:
Solaris, AIX, HPUX/IA64, FreeBSD
systems that don't return an error:
HP-UX/HPPA, Tru64 5.1, IRIX 6.5, linux/glibc, Mac O
I just tried to figure out lcov, and ran the testsuite with --coverage.
http://pogma.com/lcov/libltdl/index.html
I'll try at some stage to automate the process and do it weekly or so.
Peter
___
http://lists.gnu.org/mailman/listinfo/libtool
On 06/10/2010 12:33 AM, Peter O'Gorman wrote:
At least glibc and Mac OS X reset the dlerror() string to NULL every
time a dl*() api is called (I will check what other systems do in the
next few days). This is so programmers can do:
Sigh, but FreeBSD doesn't.
dlopen nonexisting f
On 06/10/2010 02:28 PM, Bob Friesenhahn wrote:
On Thu, 10 Jun 2010, Peter O'Gorman wrote:
As I am sure many are aware, libltdl's error reporting is pretty dumb,
lt_dlerror() regularly reports things like "file not found" where the
actual problem might be something complet
On 06/10/2010 09:45 AM, Gary V. Vaughan wrote:
I think it would be better in c++.
No, that would mean you have to jump through hoops to use it from C.
And it would make me cry myself to sleep at night. I avoid C++, Perl,
McDonalds and suicide bomber recruiters as much as I possibly can. I'm
Aside: I'm leaning away from upholding the
'drop-in-with-minimum-edits' philosophy for my rewrite, since the
dlfcn.h API seems like a pretty bad design to me. After all, all
people really need to do is call functions with a known name and
known signature which happen to be in another library. I'm
Hi,
As I am sure many are aware, libltdl's error reporting is pretty dumb,
lt_dlerror() regularly reports things like "file not found" where the
actual problem might be something completely different, and a reasonable
error string may be readily available from dlerror().
When I looked at the
On 04/23/2010 01:30 PM, Vincent Torri wrote:
>
>
> -- Forwarded message --
> Date: Fri, 23 Apr 2010 12:27:27 -0600
> From: Eric Blake
> To: Vincent Torri
> Cc: autoc...@gnu.org
> Subject: Re: use of shrext_cmds on mac os x
>
> On 04/23/2010 12:09 PM, Vincent Torri wrote:
>>
>>
On 04/22/2010 12:01 AM, Vincent Torri wrote:
>
>
> On Wed, 21 Apr 2010, Peter O'Gorman wrote:
>
>> On 04/21/2010 04:00 PM, Vincent Torri wrote:
>>>
>>> Hey,
>>>
>>> A guy mentioned that problem: on mac os x, a "standard" share
On 04/21/2010 04:00 PM, Vincent Torri wrote:
>
> Hey,
>
> A guy mentioned that problem: on mac os x, a "standard" shared lib has
> suffix name .dylib:
>
> lib_LTLIBRARIES = libfoo.la --> libfoo.dylib
>
> but with a "module":
>
> pkg_LTLIBRARIES = bar.la
> bar_la_LDFLAGS = -module -avoid-versi
version of libtool is generating this? Where is the -r coming from?
Why are you passing -Map instead of -map?
Passing -Wl,-map,libbuffer.map will likely work, but I am not sure why
the -Wl, quoting was removed above. Nor am I sure why gcc generates no
warning or error when i
't help you, then I suggest you post the
> output of the failing 'make' command.
Hi Ralf, Prokash,
Apple's ld takes a -map argument that generates a map file along
with the output. A quick test using ./libtool --mode=link --tag=CC gcc
-o libfoo.la foo.lo -rpath /foo -Wl,-map,
(there used to be one flat namespace
X11 library, I think that changed). Two level namespace is faster, and
solves numerous portability problems.
Peter
--
Peter O'Gorman
http://pogma.com
___
http://lists.gnu.org/mailman/listinfo/libtool
problem on Mac OS X.
Peter
--
Peter O'Gorman
http://pogma.com
___
http://lists.gnu.org/mailman/listinfo/libtool
ly covered, please let us know.
libltdl itself does not even build with g++, that check does not belong,
really.
Peter
--
Peter O'Gorman
http://pogma.com
___
http://lists.gnu.org/mailman/listinfo/libtool
nk that's about all, I will provide patches for HACKING and
Makefile.maint later.
Peter
--
Peter O'Gorman
http://pogma.com
___
http://lists.gnu.org/mailman/listinfo/libtool
If you happen to be stuck using an older libltdl for some reason, the
attached untested patch should give you the same changes in behavior as
the badly numbered 2.2.6b release.
Peter
--
Peter O'Gorman
http://pogma.com
diff -urN libtool-1.5.26.orig/libltdl/ltdl.c libtool-1.5.26/libltdl/l
On 11/16/2009 09:32 AM, Jeff Squyres wrote:
On Nov 16, 2009, at 7:21 AM, Peter O'Gorman wrote:
We are intending to release 2.2.8 sometime (hopefully soon) with all
the new features and lots of bug fixes from git HEAD.
So why not call this release 2.2.8 and bump the version number of the
ugfixes to libltdl that were deemed
important enough to warrant a separate release from the "stable" 2.2.6
series.
Peter
--
Peter O'Gorman
http://pogma.com
___
http://lists.gnu.org/mailman/listinfo/libtool
So, I screwed up ...
Yes, I know it's not best. I tagged 2.2.6b yesterday, and moved the tag
this morning, so you may have the tag pointing at the wrong commit.
Sorry,
Peter
--
Peter O'Gorman
http://pogma.com
___
http://lists.gnu.o
We are pleased to announce the release of GNU Libtool 2.2.6b.
GNU Libtool hides the complexity of using shared libraries behind a
consistent, portable interface. GNU Libtool ships with GNU libltdl,
which hides the complexity of loading dynamic runtime libraries
(modules) behind a consistent, port
tches and rerun the
testsuite in a timely fashion for any advances made by fellow libtoolers.
I just looked at this, and would guess that most are the same -
bash: {CXX:-g++}: command not found
Missing a $.
Peter
--
Peter O'Gorman
http:/
ibtool, it is a packaging issue.
If libfoo went from 22.0.0 (provided by foo-2.0.0) to 22.1.0 (provided
by foo-2.0.2) then new binary packages created that use the new libfoo
need to have a versioned dependency >= foo-2.0.2, end of story.
Peter
--
Peter O'Gorma
is passed an absolute path, it shouldn't really be
searching at all. I'd call that a different bug though.
Feel free to delve in and propose patches.
Peter
--
Peter O'Gorman
http://pogma.com
___
http://lists.gnu.org/mailman/listinfo/libtool
I just did git push --all; git push --tags; to update savannah's copy of
the repository.
So much easier than last time :)
Peter
--
Peter O'Gorman
http://pogma.com
___
http://lists.gnu.org/mailman/listinfo/libtool
This libjpeg.la is
a libtool created file that instructs libtool that the libjpeg.a sitting
next to it is a libtool convenience archive.
How was the file libjpeg.la, in the directory
/home/bubla/projects/devil_modular/lib created?
Peter
--
Peter O'Gorman
http://pogma.com
___
http://lists.gnu.org/mailman/listinfo/libtool
ular/lib/libjpeg.la is a libtool
convenience library (or at least libtool thinks it is). How was it
created? What is the Makefile.am rule for it?
Peter
--
Peter O'Gorman
http://pogma.com
___
http://lists.gnu.org/mailman/listinfo/libtool
/lib64/
libbfd.a?
Sorry for the length of this message. Thanks in advance for any
help.
Regards,
-Maynard Johnson
--
Peter O'Gorman
http://pogma.com
___
http://lists.gnu.org/mailman/listinfo/libtool
10.dylib". I tested replacing the
"-L -l" combination with the path to the dylib, and that seems to
work.
So it seems to be a bug in libtool.
Sorry, I did not get back to you.
Could you please send the output of ./libtool --config.
Thanks,
Peter
--
Peter O'Gorman
http://pogma.
Update of sr #106497 (project libtool):
Status:None => Done
Assigned to:None => pogma
Open/Closed:Open => Closed
_
html/autotools-announce/2008-09/msg1.html
I can only suggest you mv libtool-2.2.6a.tar.gz libtool-2.2.6.tar.gz and
pass that tarball to your auto-build scripts.
Peter
--
Peter O'Gorman
http://pogma.com
___
http://lists.gnu.org/mailman/listinfo/libtool
a linker script to limit exported
symbols on linux if ld supports it.
Peter
--
Peter O'Gorman
http://pogma.com
___
http://lists.gnu.org/mailman/listinfo/libtool
$ /usr/bin/glibtool --version
ltmain.sh (GNU libtool) 1.5.22 (1.1220.2.365 2005/12/18 22:14:06)
on a more recent libtool-2.2.x, I get:
libtool: link: /usr/bin/g++ -Wl,-undefined -Wl,dynamic_lookup -o
.libs/java.jnilib -bundle .libs/java.o
libtool: link: dsymutil .libs/java.jnilib || :
P
ame failure)
Your configure script adds spaces after -I and -L before the directory.
GCC is ok with this, libtool not so much.
Peter
--
Peter O'Gorman
http://pogma.com
--- configure.in~ 2008-07-17 18:04:22.0 -0500
+++ configure.in 2008-07-31 14:13:35.0 -0500
@@ -39,9 +
s do things differently
> depending on a symlink name?
The test is:
case $cc_basename in
CC*)
So this does not match 'sunCC'.
I guess we can change the test to match sunCC*|CC*).
Peter
--
Peter O'Gorman
http://pogma.com
___
http://lists.gnu.org/mailman/listinfo/libtool
ke use of lt_dlopen, I would
suggest using sed to modify the .la files after the root is complete.
Peter
--
Peter O'Gorman
http://pogma.com
___
http://lists.gnu.org/mailman/listinfo/libtool
root so that they contain the actual
location of the libraries in libdir.
Peter
--
Peter O'Gorman
http://pogma.com
___
http://lists.gnu.org/mailman/listinfo/libtool
Sandeep Puddupakkam (spuddupa) wrote:
> The log file generated is big (400k) and my mail is not going thru. If
> anyone wants to look at the logfile, I can mail it to you directly.
>
Please compress it and send it to the list.
Peter
--
Peter O'Gorman
ht
-obsolete version.
Thanks, fixed.
Peter
--
Peter O'Gorman
http://pogma.com
___
http://lists.gnu.org/mailman/listinfo/libtool
Christopher Hulbert wrote:
> On Fri, Jun 13, 2008 at 11:55 AM, Peter O'Gorman <[EMAIL PROTECTED]> wrote:
>> Christopher Hulbert wrote:
>>
>>> GIT version still reports that the ifort linker does not support
>>> shared libraries. The config.log is
Christopher Hulbert wrote:
> GIT version still reports that the ifort linker does not support
> shared libraries. The config.log is attached.
Hi Chris,
Your config.log confirms that ifort does not define __GNUC__, thanks.
Could you confirm that this patch fixes it.
Peter
--
Peter O&
ibtool using package (or from libtool itself) without this patch
applied.
Thanks,
Peter
--
Peter O'Gorman
http://pogma.com
___
http://lists.gnu.org/mailman/listinfo/libtool
is being installed
with the archive.
dump -X32_64 -H /path/to/libnetcdf.a should show you the shared members.
Peter
--
Peter O'Gorman
http://pogma.com
___
http://lists.gnu.org/mailman/listinfo/libtool
Peter O'Gorman wrote:
> Richard Purdie wrote:
>> Hi,
>>
>> As previously mentioned, I've been stress testing libtool 2.2.2 with
>> Poky a bit.
>>
>> I've found one issue when I tested the darwin builds, specifically that
>> it tried to
rsions with the host
> prefix which my setup has. I fixed this with the patch below which is
> fine for Poky since its always cross compiling but its a sign a better
> fix is probably needed in general.
Thanks,
I have pushed this, it also cleans up the sed sed ech
ment is almost entirely due to Ralf, so I encourage everyone
who is subscribed to this list to seek him out and buy him many beers.
Peter
--
Peter O'Gorman
http://pogma.com
___
http://lists.gnu.org/mailman/listinfo/libtool
_compiler_wl eval
gtk_export_dynamic=\"$export_dynamic_flag_spec\"
For C++, it would be wl=$lt_prog_compiler_wl_CXX etc.
Peter
--
Peter O'Gorman
http://pogma.com
___
http://lists.gnu.org/mailman/listinfo/libtool
, of course, it is preferred to use the vars directly, creating
libtool just to check these is expensive and pointless.
Peter
--
Peter O'Gorman
http://pogma.com
___
http://lists.gnu.org/mailman/listinfo/libtool
mbols. This causes
> link time error. I fixed this problem by changing the name in the ltdl.h
> file to match the symbol in the libraries.
When linking libltdl?
What are the errors that you saw? And what changes did you have to make?
Peter
--
Peter O
Ralf Wildenhues wrote:
> * Bob Friesenhahn wrote on Thu, Apr 10, 2008 at 07:51:57AM CEST:
>> On Wed, 9 Apr 2008, Peter O'Gorman wrote:
>>> This is a list off shell functions that appear in the generated libtool
>>> script on my linux system (one of Ralf's p
Bob Friesenhahn wrote:
> On Wed, 9 Apr 2008, Peter O'Gorman wrote:
>>
>> (using bash)
>> $ for y in {1..100}; do echo "func_notused${y} () {" >> parse.sh; for x
>> in {1..1}; do echo foo >> parse.sh; done; echo '}' >> par
fer_tag ()
func_generate_dlsyms ()
func_extract_an_archive ()
func_extract_archives ()
func_write_libtool_object ()
func_mode_compile ()
func_mode_execute ()
func_mode_finish ()
func_mode_install ()
func_emit_wrapper ()
func_emit_cwrapperexe_src ()
func_mode_link ()
func_mode_uninstall ()
Peter
--
Pet
s
On mac os x:
$ time zsh parse.sh
Done
real0m1.429s
user0m1.176s
sys 0m0.193s
$ time bash parse.sh
Done
real0m4.921s
user0m4.706s
sys 0m0.215s
$ time ksh parse.sh
Done
real5m31.311s ***
user5m29.284s
sys 0m1.876s
I know that
compile mode too.
Peter
--
Peter O'Gorman
http://pogma.com
___
http://lists.gnu.org/mailman/listinfo/libtool
opyright assignment forms etc.
Peter
--
Peter O'Gorman
http://pogma.com
___
http://lists.gnu.org/mailman/listinfo/libtool
lease present a more convincing argument.
Peter
--
Peter O'Gorman
http://pogma.com
___
http://lists.gnu.org/mailman/listinfo/libtool
Alon Bar-Lev wrote:
> On 3/27/08, Peter O'Gorman <[EMAIL PROTECTED]> wrote:
>> Why? I can understand wanting to change the extension, we have -shrext
>> for that. But why do you want the user to have the option to set the name?
>
> Hi!
>
> Because I generat
Why? I can understand wanting to change the extension, we have -shrext
for that. But why do you want the user to have the option to set the name?
Peter
--
Peter O'Gorman
http://pogma.com
___
http://lists.gnu.org/mailman/listinfo/libtool
chunk of changelog), but if it is
decided that we do, then we can just make do with the topmost date in
the changelog file.
Peter
--
Peter O'Gorman
http://pogma.com
___
http://lists.gnu.org/mailman/listinfo/libtool
1 - 100 of 416 matches
Mail list logo
