Re: Running an uninstalled executable

El Tue, 12 May 2015 11:38:42 +0200 Alberto Luaces escribió: > Hello, > > in an autoconf+automake+libtool C++ project containing only one > program, I want to run the executable before installing it. > > Reading the manual I thought that it could be done with > > libtool --mode=execute program_b

Re: Fwd: Fwd: android support

Hello, Glad seeing this being addressed :-) On Tue, Sep 10, 2013 at 12:41 AM, Brooks Moses wrote: > Hello, Marco, > > Thanks for pinging this -- I'm trying to work through some of the libtool > patch backlog, and I'll have a look at this in the next few days. > > I

Re: Avoid exporting of internal symbols

El Martes, 5 de marzo de 2013 18:53:37 Satz Klauer escribió: > __attribute__ ((visibility ("default"))) And why not __attribute__ ((visibility ("hidden"))) for symbols you don't want to be exported and __attribute__ ((visibility ("default"))) for the ones you want to be exported? You can also def

Re: Avoid exporting of internal symbols

I cant remember now the syntax, but maybe the gcc hidden visibility attribute is what you are looking for. El 04/03/2013 08:06, "Satz Klauer" escribió: > I'm creating a shared library using libtool: > > libtool --mode=compile g++ -Wall -fPIC -shared -Wno-unused > -Wno-unused-result $(CFLAGS) $(LF

RE: Help needed to build shared library with libtool

Hi Peter I have tried using just g++ (no libtool) and the link succeeds. On this occasion it seems easiest for me just not to use libtool. Thanks for your help and advice. Best regards David ___ https://lists.gnu.org/mailman/listinfo/libtool

RE: Help needed to build shared library with libtool

e better off > not using libtool at all, and just doing > g++ -shared -o libGUI.so Well that would be fine. We just need to build for Linux. To be honest I don't know why we are using libtool. I will try just using g++ ... Thanks again David ___ https://lists.gnu.org/mailman/listinfo/libtool

RE: Help needed to build shared library with libtool

r/lib/gcc/x86_64-redhat-linux/4.4.4/crtendS.o /usr/lib/gcc/x86_64-redhat-linux/4.4.4/../../../../lib64/crtn.o -pthread -pthread -Wl,-soname -Wl,libGUI.so.0 -o libGUI.so.0.0.0 libtool: link: (cd ) ln: creating symbolic link `libGUI.so.0': Operation not suppor

Help needed to build shared library with libtool

btool created a command that started with: g++ -shared -o /libGUI.so whereas the failing command (above) starts with: libtool: link: g++ -o libGUI.so I realise that the absence of '-shared' in the latter is probably causing my problem.  Why is it not present ple

Help needed to build shared library with libtool

btool created a command that started with: g++ -shared -o /libGUI.so whereas the failing command (above) starts with: libtool: link: g++ -o libGUI.so I realise that the absence of '-shared' in the latter is probably causing my problem.  Why is it not present ple

Help needed to build shared library with libtool

btool created a command that started with: g++ -shared -o /libGUI.so whereas the failing command (above) starts with: libtool: link: g++ -o libGUI.so I realise that the absence of '-shared' in the latter is probably causing my problem. Why is it not present ple

Re: 32/64 bit on sun4u

On 02/16/11 05:46 PM, Patrick Welche wrote: On another list a poster thought that libtool was doing the wrong thing(tm), but it seems to be rather that config.guess needs to be given hints about sun4u. This means that this probably isn't the right list - but which one is? Essentially, he is runn

Re: Linking problem building iconv on Solaris x86

On 08/29/10 10:27 AM, Ralf Wildenhues wrote: For others looking at the same issue: We hashed this issue out off-list, using configure CC='gcc -m64' works, just configure CFLAGS=-m64 fails. Cheers, Ralf Thank you Ralf. I had seen a similar issues with some other packages when setting

Re: Link Time Optimization

I feel like lto is something that is sufficient important to be tested as soon as possible, and, imho, gives as a new interesting level of optimization. Personally, I use gentoo and try to optimize as much as I can.. Anyway, thanks for looking at th

Link Time Optimization

I've been searching mailing list for supporting -flto in libtool, and seen several (commited?) patches. The problem is that I've tried git version of libtool (trunk) and still it is not supported since any program will compile with -flto (for example, mysql-5.1.50). Then, I have several questi

Re: Linking problem building iconv on Solaris x86

On 08/11/10 05:33 AM, Ralf Wildenhues wrote: * Dr. David Kirkby wrote on Tue, Aug 10, 2010 at 11:33:36PM CEST: Hrmpf. On Solaris, we add '${wl}-z ${wl}text' to archive_cmds and archive_expsyms_cmds unconditionally, as opposed to only with -no-undefined. I wonder why that is the

Re: Linking problem building iconv on Solaris x86

On 08/10/10 10:10 PM, Ralf Wildenhues wrote: Hello David, * Dr. David Kirkby wrote on Tue, Aug 10, 2010 at 10:48:25PM CEST: On 08/10/10 09:28 PM, Ralf Wildenhues wrote: /bin/bash ../libtool --mode=link gcc -m64 -fvisibility=hidden -o libiconv.la -rpath /home/drkirkby/fulvia/64/sage-4.5.3

Re: Linking problem building iconv on Solaris x86

On 08/10/10 09:28 PM, Ralf Wildenhues wrote: /bin/bash ../libtool --mode=link gcc -m64 -fvisibility=hidden -o libiconv.la -rpath /home/drkirkby/fulvia/64/sage-4.5.3.alpha0/local/lib -version-info 7:0:5 iconv.lo localcharset.lo relocatable.lo No, it does not. (sage subshell) fulvia:lib drkir

Linking problem building iconv on Solaris x86

I'm trying to build a 64-bit version of libiconv on Some Solaris machines. This works on all SPARC, and on 06/2009 release of OpenSolaris on an Intel Xeon. But I'm getting error messages at the link phase on two machines * Solaris 10 update 5 (released 05/2008) on x86 * OpenSolaris 11/2008 on x

Problem when a 32-bit library is linked instead of a 64-bit library

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 this case. http://trac.sagemath.org/sage_trac/ticket/7864 lists a build failure in the Sag

Re: Getting executable to link to libtool-built library

Hello, On Mon, Dec 28, 2009 at 3:22 AM, Alberto Luaces wrote: > David Bruce writes: > >> Hello, >> >> I have two related programs (tuxmath and tuxtype) that share a lot of >> code in a human-maintained, copy-and-past fashion.  We have been >> working o

Getting executable to link to libtool-built library

kcommon.la in tuxmath's Makefile.am, which fails with "no rule to make libt4kcommon.la needed by tuxmath". However, I don't think LDADD is the correct approach here anyway. Anyone have any suggestions for the probably obvious step I&#x

Re: Getting executable to link to libtool-built library

self. Anyway, after I supplied the definitions and rebuilt the library, I can link tuxmath to it. Anyway, if someone would confirm that AC_CHECK_LIB is the right way to do this, I would be a most appreciative libtool newbie. Thanks, David Bruce ___ ht

Re: release procedure

) use libltdl in C++ projects. Sure, the header forces symbols to have C-linkage in any case, but I'd sleep better knowing this was covered somehow. Fang David Fang http://www.csl.cornell.edu/~fang/ http://www.achronix.com/ ___ http://lists.gnu.o

RE: control where win32 DLLs get installed behavior

On November 1, 2009, Ralf Wildenhues wrote: > Yes. We haven't figured out whether and when automake > should do this automatically. If we do, then a future > release of Automake may change this. Until then you can > use add `-bindir $(bindir)' to either AM_LDFLAGS (if this > is to be set for a

control where win32 DLLs get installed behavior

I've grabbed the latest libtool sources from the pr-msvc-support branch, hoping to get more control over where libtool installs DLLs. Unfortunately, my DLLs are going to the same place they were before. I got libtool to do the advertised thing when I invoke it manually, like this: /bin/sh ./libt

RE: extra exports with libtool (pr-msvc-support)

> > I just tried this by adding > > > > libfoo_la_LDFLAGS += -export-symbols symfile > > > > and manually creating an empty file named symfile in the > > example I posted earlier. Now the only symbol that gets > > exported is the one decorated with dllexport. Thanks > > for the workaround. One

RE: pr-msvc-support: building .DLLs with symbols

> You want to send -DEBUG to link.exe, not to cl.exe. I'm > sure you know this, but simply adding -DEBUG to LDFLAGS is > not the way you do this. The correct way would be to use > -Wl,-DEBUG. If the msvc stuff were complete, libtool would > then feed -DEBUG to the linker. But this does not > curre

pr-msvc-support: building .DLLs with symbols

Even when I set LDFLAGS to -DEBUG, I can't seem to get libtool to use that flag when building a dll. So, I want to get debug information into the .dll but it's not there. I verified that it's not there by looking at the output of dumpbin -all. Here's the libtool invocation and output for the lin

RE: extra exports with libtool (pr-msvc-support)

> Indeed, good to know. Your input made me realize that it > should be possible to work around the extra exports with > something like -export-symbols-regex=probably_not_a_match > or with an empty SYMFILE and -export-symbols=SYMFILE > > Untested though, but the linker should then pick up the > sym

RE: extra exports with libtool (pr-msvc-support)

> The portable way to specify which symbols you want to be > visible (with libtool) is to use -export-symbols or > -export-symbols-regex, IIUC. So, assuming you have some > visibility requirements you are better off using those > options anyway. Lightbulb goes on a bit. Whatever happens with __de

RE: extra exports with libtool (pr-msvc-support)

Re-ordering paragraphs... > Not on all systems, but I think that will happen with gcc/ld though. > I think they will only export dllexported symbols if at least one such > symbol exist. However, this causes some trouble if you e.g. have a > library that is not decorated with dllexport and which us

extra exports with libtool (pr-msvc-support)

I'm running into a situation where libtool is exporting something I don't expect it to. I've attached a tarball that demonstrates this. So it's more clear what I'm talking about without having to dive into the attachment, I'm compiling a shared library that I think should have one export. But

RE: different flags for static and shared

> > #if BUILDING_LIBFOO && HAVE_VISIBILITY > > #define LIBFOO_DLL_EXPORTED __attribute__((__visibility__("default"))) > > #elif BUILDING_LIBFOO && defined _MSC_VER > > #define LIBFOO_DLL_EXPORTED __declspec(dllexport) > > #elif defined _MSC_VER > > #define LIBFOO_DLL_E

RE: global_symbol_pipe not picking up an initialized global variable with msvc

> I tried to reproduce (but failed, so I think the symbol pipe is > definitely out of the loop): I agree. I was on the road to put this together when I found the broken UTL_EXPORT as the culprit. Thanks for going to the trouble to build a simple example. By bad for not doing this before I poste

RE: global_symbol_pipe not picking up an initialized globalvariable with msvc

> > UTL_EXPORT becomes __declspec(dllexport) when compiling > > the shared lib, __declspec(dllimport) when compiling the > > executable that uses it. > > did you double check if that really works on both sides? > your problem sound to me as if dllimport is missing > somewhere. Not enough. I chec

global_symbol_pipe not picking up an initialized global variable with msvc

I'm pretty sure I'm running into a pr-msvc-support-specific problem but I'm still learning about libtool so... I'm trying to get rid of unresolved externs when linked an executable against a libtool shared library compiled with msvc. The unresolved externs are global variables. The code in quest

RE: using $bindir when installing using msys

> > I'm curious why libtool doesn't seem to be honoring the > > --bindir option I passed to configure. > > A fix is being worked on: > > Sorry for the noise. -DB ___

using $bindir when installing using msys

I've run into a situation where libtool isn't installing my DLL where I expect it to. I'm invoking configure with these options: --prefix=/c/foo/install --libdir=/c/foo/install/lib/Debug --bindir=/c/foo/install/bin/Debug but when I run make install, libtool leaves me with: $ ls /c/foo/install/l

RE: different flags for static and shared

On July 25, 2009, Ralf Wildenhues wrote: > * David Byron wrote on Tue, Jun 30, 2009 at 12:22:52AM > CEST: > > > In the case where a build directory is configured for > > static only (e.g. invoked with --disable-shared) I can > > add -DLIBFOO_STATIC to one of the CPPFL

different flags for static and shared

Sorry if this is a FAQ. I'm building a library using the pr-msvc-support branch of libtool so I'm using native MSVC tools. When building a shared lib I'm doing one of the methods prescribed here: http://www.gnu.org/software/gnulib/manual/html_node/Exported-Symbols-of-Shar ed-Libraries.html Spec

Re: Problem upgrading Xorg--libtool issue?

Hi Ralf, Thanks for the reply. I tried the dummy lib option and amazingly it worked. As far as I can tell, all the apps I've tried (whether part of xorg or not) seeem to work. David On Fri, 2009-04-10 at 17:50 +0200, Ralf Wildenhues wrote: > Hello David, > > sorry

Problem upgrading Xorg--libtool issue?

st an alternate solution. For example, can I simply remove the libxcb-xlib references from all the .la files? How about simply making a dummy libxcb-xlib.so library? Anything else? Thanks in advance. Please CC me directly as I don't subscribe

Re: IA64 HP-UX libtool / gcc question about shared libraries

th works but it searches for build directories not present on the install system. David ___ http://lists.gnu.org/mailman/listinfo/libtool

Re: Announcing Dolt, a drop-in Libtool replacement which cuts build times in half

enSolaris, Darwin. -- David Johnson ___ http://lists.gnu.org/mailman/listinfo/libtool

Re: GNU Libtool 2.2 released.

=2 -C % make && make -k check ... All 124 tests passed and 63 tests behaved as expected. 1 test was skipped. (skipped #55: template test with subdirs) Looking forward to using 2.2! Fang David Fang Computer Systems Laboratory Electrical & Computer Engineering Cornel

libtool shouldn't automatically link against libc on hppa*-*-hpux*

st never linked against the old versions. HP never links shared its libraries against libc. Dave -- J. David Anglin [EMAIL PROTECTED] National Research Council of Canada (613) 990-0752 (F

RE: passing flags to the librarian

On Tuesday, December 11, 2007, Duft Markus wrote: > You may wanr to have a look at parity > (http://www.sf.net/projects/parity). It was written more or less to be > more powerfull than cccl (but for now is only tested with interix, not > cygwin). I'm going to stick with cccl for now. > Also par

passing flags to the librarian

I'm building a libtool-based package (pcre) using Microsoft command line tools in a cygwin shell. I use a wrapper script for the compiler and linker (cccl), but the librarian (lib) gets invoked directly. I'd like to specify the /LTCG (link time code generation flag) to the librarian. Beats me wh

Re: C++ Plugins and virtual destructors.

tion outside of main, i.e. one thrown and uncaught during statics. I'm not sure a C++ plug-in would work in C, but if you had a function for cleaning up resources (something likely to appear in a dtor), you could register a cleanup function with atexit(). Fang David Fang Computer Systems La

Re: Sun Studio linking issues in Solaris 9

that part out of the Makefile.in and forward your response back to him. I don't see how libtool could be at fault here when the arguments are being given to libtool incorrectly. Thanks for the help anyways, -Dave -- ==== David Halik Student Programmer OSS/NBCS - OIT

Sun Studio linking issues in Solaris 9

$(LIBTOOLFLAGS) --mode=link $(CCLD) $(AM_CFLAGS) $(CFLAGS) \ - $(libauthldap_la_LDFLAGS) $(LDFLAGS) -o $@ + $(LDFLAGS) $(libauthldap_la_LDFLAGS) -o $@ am_libauthmysql_la_OBJECTS = authmysql.lo preauthmysql.lo \ authmysqllib.lo libauthmysql_la_OB

Re: dlopening installable ltdl modules failing (OS X problem only)

Hi, Must've missed this message earlier... > > The executable takes command-line arguments that call lt_dladdsearchpath > > (option -L) and lt_dlopenext (option -l). The file, ../../lib/mymodule.la > > has already been built at the time of testing. The executable is invoked > > with "-L.

Re: dlopening installable ltdl modules failing (OS X problem only)

> > > It is entirely possible that you've found a bug, Mac OS X should work > > > the same as linux et.al. in this regard. Does the module itself have any > > > dependencies that possibly are not being found (check with otool -L > > > mymodule.0.so)? If that is not the case, please send more info (

Re: dlopening installable ltdl modules failing (OS X problem only)

> > It is entirely possible that you've found a bug, Mac OS X should work > > the same as linux et.al. in this regard. Does the module itself have any > > dependencies that possibly are not being found (check with otool -L > > mymodule.0.so)? If that is not the case, please send more info (if you >

Re: dlopening installable ltdl modules failing (OS X problem only)

> > I'm having a problem testing some libtool (ltdl) modules, but only > > on OS X (darwin7 and darwin8, libtool 1.5.22 and .24). My executable > > lt_dlopens a .la library in another built directory (during make check > > testing), and fails with an lt_dlerror message like: > > > > dlopen(../

dlopening installable ltdl modules failing (OS X problem only)

with more concrete details if I haven't been clear enough. Thanks in advance. Fang David Fang Computer Systems Laboratory Electrical & Computer Engineering Cornell University http://www.csl.cornell.edu/~fang/ -- (2400 baud? Netscape 3.0?? lynx??? No problem!) ___

Re: libltdl's (1.5.24) Makefile.in configure ... autotool version mixing?

I am not going to release 1.5.26 for this though :) Not critical for sure, but perhaps worth noting somewhere in the docs? That libltdl's build support files are generated with version X, but the above steps can be done to regenerate with version Y. I can see this being applicable to

libltdl's (1.5.24) Makefile.in configure ... autotool version mixing?

nonexistent 'mkinstalldirs' and the top-level dist/distcheck seems happy. Is this a sin I'm going to pay for? Thanks in advance. David Fang Computer Systems Laboratory Electrical & Computer Engineering Cornell University http://www.csl.cornell.edu/~f

Re: force shared noinst_LTLIBRARIES?

> On Thu, July 26, 2007 01:20, David Fang wrote: > > I wasn't able to find an answer for this in the libtool/automake > > manuals: Is there a way to force libtool (with automake) to create the > > shared version of an uninstalled library? I would like to use libtool

force shared noinst_LTLIBRARIES?

f hook to remove unwanted installs (ick). Or is there a simpler (yet still portable) way to do what I want? Thanks in advance. Fang David Fang Computer Systems Laboratory Electrical & Computer Engineering Cornell University http://www.csl.cornell.edu/~fang/ -- (2400 baud? Nets

Re: [boost] wgcc 2.0 RC1 released

"Duft Markus" <[EMAIL PROTECTED]> writes: > When building with wgcc there are a few benefits: > > Wgcc uses the native windows compiler to build (so the code may or may > not be faster ;o)) and whats a lot more important: the debug > information produced is readable by visual studio, so you can de

Re: wgcc 2.0 RC1 released

"Duft Markus" <[EMAIL PROTECTED]> writes: > Hi again! > > For all interested in native Windows binaries built with Autotools and > mnay other interesting things: I'm not sure whether this is on-topic for Boost; it seems of somewhat borderline relevance. However, now that you've started the thr

Re: automake/libtool question

Thank you for responding Ralf, On 9/12/06, Ralf Wildenhues <[EMAIL PROTECTED]> wrote: [ Cc:ing both lists; let's drop the automake list ] Hello David, * David Everly wrote on Tue, Sep 12, 2006 at 01:02:47AM CEST: > > HP-UX B.11.23 U ia64 > automake (GNU automake) 1

Re: handling of missing AR

configure detects an inconsistency, this is a "hard fail" and it bails out.) This has had the huge benefit of giving new end-users a "configure" that actually completes. They can then quickly move on to a final product (albeit one that may lack some desirable (but not vit

Re: Libtool(?) frustrations

Peter O'Gorman wrote: > David N. Welton wrote: > > | That comes from this Makefile.am line: > | > | lib_libexec_LTLIBRARIES = librivet.la librivetparser.la > | > | What might be the cause of this problem? Is there a better place to ask? > | > | Thanks for your hel

Libtool(?) frustrations

r/local/src/rivet-0.7.0/src' make: *** [install-recursive] Error 1 That comes from this Makefile.am line: lib_libexec_LTLIBRARIES = librivet.la librivetparser.la What might be the cause of this problem? Is there a better place to ask? Thanks for your help

ltdl dlpreopen behavior

ith a substitution into my actual C code, but thats kind of ugly... Any suggestions? I imagine my program would be a fairly common design wrt builtin+optional modules (the linux kernel is an obvious example). Thanks, David ___ http://lists.gnu.org/mailman/listinfo/libtool

Re: solaris 10: [EMAIL PROTECTED]

On Mon, 4 Jul 2005, David Lee wrote: [...] For instance, do we _know_ that this S10/[EMAIL PROTECTED] problem is _definitely_ 100% attributable to GNU/ld? Is "libtool" known/proven to be not contributing in any way to this problem? As was mentioned in my email of 29th June, the &

Re: solaris 10: [EMAIL PROTECTED]

On Mon, 4 Jul 2005, Howard Chu wrote: Bob Friesenhahn wrote: On Mon, 4 Jul 2005, David Lee wrote: I'm using GNU/ld; but I'd be happy,as part of the experiments, to try to redirect our "gcc" to use the Solaris/ld. (How to redirect it?) I recommend that anyone wh

Re: solaris 10: [EMAIL PROTECTED]

On Wed, 29 Jun 2005, Ralf Wildenhues wrote: * David Lee wrote on Tue, Jun 28, 2005 at 07:10:59PM CEST: (Incidentally: this may or may not be relevant to the above: in my own case, I know that our GNU ld and libtool are somewhat out-of-date. So I've attempted to get libtool 1.5.18 inst

Re: solaris 10: [EMAIL PROTECTED]

On Wed, 29 Jun 2005, Ralf Wildenhues wrote: * David Lee wrote on Tue, Jun 28, 2005 at 07:10:59PM CEST: Quite a few folk seem to be having trouble linking on Solaris 10. These seem to be well-established applications, that have compiled and linked for years on a wide range of OSes, including

solaris 10: [EMAIL PROTECTED]

to the above: in my own case, I know that our GNU ld and libtool are somewhat out-of-date. So I've attempted to get libtool 1.5.18 installed. "make check" is fine on S8, but has a failure in "mdemo2-make.test" on S10. If someone can guide

RE: Building JNI libraries on MacOS X and other systems

" on the link line. To use it for jnilibs, you will have to have some configury to set the option on MacOS X only. HTH, Robert -- ..... David L. Thompson Visualization and Imagery Solutions, Inc. mail

Lower your payments

___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool

Linking problem

n both of the sets are PIC. So there shouldn't be any difference between them. But when I link the library using the files in "." directory - every thing is ok. Do you happen to know, where the problem is? David P.S.: I have the following flags: CXXFLAGS = -noimplicit_include -p

Re: hppa*64* and dependent libraries

a64-hpux, so I think Steve Ellcey at HP needs to be involved in the discussion. Dave -- J. David Anglin [EMAIL PROTECTED] National Research Council of Canada (613) 990-0752 (FAX: 952-6605) ___ Libtool

Re: hppa*64* and dependent libraries

ectory in the embedded path. I wonder if libtool could check for a user "+b" option and append the specified path to the accumulated rpath. Dave -- J. David Anglin [EMAIL PROTECTED] National Research Council of Canada (613) 990-0752 (FA

Re: hppa*64* and dependent libraries

prior to install. This all seems reasonable to me. This was generated using my original libtool patch for binutils. Dave -- J. David Anglin [EMAIL PROTECTED] National Research Council of Canada (613) 990-0752 (FAX: 952-6605)

Re: hppa*64* and dependent libraries

-L" and "-l", and NOT use "+b". The linker will also add LPATH to the end of the constructed embedded path. Dave -- J. David Anglin [EMAIL PROTECTED] National Research Council of Canada (613) 990-0752 (FAX: 952-6605) _

Re: hppa*64* and dependent libraries

n specific directory. This caused libraries like libstdc++.sl to have dependencies which included the path to the gcc tool directory. If you removed the gcc tool directory, then applications linked with libstdc++.sl no longer worked. I removed the dot dots from the dependencies a few months ag

Re: hppa*64* and dependent libraries

to add to the confusion, this is my original patch. Dave -- J. David Anglin [EMAIL PROTECTED] National Research Council of Canada (613) 990-0752 (FAX: 952-6605) 2002-07-09 John David Anglin <[EMAIL PROTECTED]> * libtool.m4

Re: Setting LD tool default to ld breaks configure check for ld used by GCC

cript, the libtool script then sets LD to ld program used by GCC. However, this define for LD isn't a proper default. So, I am wondering if the libtool script should also reset LD when LD=ld? Dave -- J. David Anglin [EMAIL PROTECTED] National Rese

Re: [Fink-devel] Re: libtool "module" behavior and darwin

-BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 >Feel free to take the patches from NetBSD pkgsrc and makes noises with the KDE people. http://www.netbsd.org/Documentation/software/packages.html No need to make noise with the KDE people, I am reading this list *grins* If you have a patch a

Re: getting a locally built library

On Thursday, November 14, 2002, at 11:36 AM, Bruce Korb wrote: You're specifically adding -L/sw/lib. Don't. It will get added by the configure script in the right place automatically, as long as /sw/bin/guile-config and xml2-config are properly found with the PATH variable. Gotcha. Removing

Re: getting a locally built library

On Thursday, November 14, 2002, at 08:39 AM, Alexandre Duret-Lutz wrote: David, could you explain where `-L../autoopts/.libs -lopts' comes from? Sure. Here are my original libtool link and compiler link commands: /bin/sh ../libtool --mode=link gcc -g -O2 -L/sw/lib -o autogen au

Re: Cygwin List O' Issues...[make install DESTDIR=]

* Charles Wilson <[EMAIL PROTECTED]> [20021030 21:20]: > David I. Lehn wrote: > > >Could someone -please- either let all of us know how to properly deal > >with this relink issue or just apply the ltmain.sh patches in the latest > >Debian libtool package to CVS?

Re: Cygwin List O' Issues...[make install DESTDIR=]

* Charles Wilson <[EMAIL PROTECTED]> [20021030 20:23]: > >2. 'make install DESTDIR=' fails (or relinks to an old version of a > >dependent lib) when the project contains dependent libraries. > > > >This bug affects all platforms. > > Demonstrates the problems with dependent shared libraries > and

Re: Libtool 1.5 && 1.4.3

* Michel LESPINASSE <[EMAIL PROTECTED]> [20021009 19:57]: > On Wed, Oct 09, 2002 at 06:27:18PM -0500, Robert Boehne wrote: > > Ok, let me see if I understand this one, > > under Linux hppa, (presumably with gcc) user has added -prefer-non-pic > > to the CFLAGS explicitly, and configured with --ena

-prefer-non-pic on hppa

I'd like to fix a build issue for mpeg2dec [1] on hppa. The Debian autobuilder failed on it [2]. The culprit appears to be the use of the --mode=compile option -prefer-non-pic. It looks like it incorrectly assumes it didn't have to use -fPIC on hppa then fails at link time [3]. The intent of u

cygwin static archives piecewise

generated libtool and the biggest problem is that /OUT:library.lib is part of the old_archive_cmds variable. So this needs to be broke up differently. Has this work already been fixed in CVS? Should I work on it? David

Re: [Mingw-users] Re: libbfd, libtool & Win32

On Monday 23 September 2002 15:30, Earnie Boyd wrote: > David Olofson wrote: > > However, it's still a very bad idea to compile tools as part of the > > application build process. ;-) > > Right, if you want to install implib as part of distributable resource > when

Re: [Mingw-users] Re: libbfd, libtool & Win32

On Monday 23 September 2002 13:00, David Olofson wrote: > On Friday 20 September 2002 22:31, Guido Draheim wrote: [...] > > In > > fact, we have a set of function names for a given lib - in its > > symbol table. > > In an export table, I would say, as most clean Win32

Re: [Mingw-users] Re: libbfd, libtool & Win32

On Friday 20 September 2002 22:31, Guido Draheim wrote: > David Olofson wrote: [...] > > How about building import libs from headers? (You need the headers to > > compile anyway...) > > Ahhm, not quite - some functions are exported only on a case-by-case > basis,

Re: [Mingw-users] Re: libbfd, libtool & Win32

ea for other reasons. Would be nice if it could be made to work somehow, but I probably won't make use of that feature myself. //David Olofson --- Programmer, Reologica Instruments AB .- Coming soon from VaporWare Inc.... | The Return of Audi

Re: Converting a project to libtool

uot; which will produce a library like libwhatever.so.0.0.3. > > Don't know why it was done this way but there must have been a good > reason. AFAIK, the idea is that the version info used during build should be usable as a way of matching applications with a *range* of library v

Re: [Mingw-users] Re: libbfd, libtool & Win32

pgen.c...? > > It is an issue with impgen. Try: > % impgen c:/winnt/system32/user32.dll > > All the names should have stdcall decoration, but don't. Ok... Is that information at all available in a DLL, or does that mean we either have to make assumptions, or just *require*

Re: [Mingw-users] Re: libbfd, libtool & Win32

On Wednesday 18 September 2002 11:46, Danny Smith wrote: > --- David Olofson <[EMAIL PROTECTED]> wrote: > On Tuesday 17 > > September 2002 20:33, Guido Draheim wrote: > > [...] > > > > > On another e-mail, you said to have some idea of the `objdump -p` >

Re: [Mingw-users] Re: libbfd, libtool & Win32

On Wednesday 18 September 2002 11:08, David Olofson wrote: [...] > Indeed, it seems that the export section is *not* really a symbol > table, which is why some DLLs can have symbols ('-syms'), while most > DLLs don't. (In fact, I think clean DLLs *shouldn't* have th

Re: [Mingw-users] Re: libbfd, libtool & Win32

with trickier stuff must upgrade their binutils to a > recent version. How does that sound? That could work. Dunno' about the reliability or portability of fitering 'objdump -p' output, but if it works for most people for now, it can at least avoid strictly forcing every cross

Re: Autoconf 2.54 is released

btool 1.4e (cvs), and tried autoconf 2.53, 2.54. Thanks -- ..... David L. Thompson The University of Montana mailto:[EMAIL PROTECTED] Computer Science Department http://www.cs.umt

  1   2   >