Re: func_convert_file_cygwin_to_w32 woes

2011-01-04 Thread Dan McMahill
On 1/4/2011 11:44 AM, Peter Rosin wrote: > Den 2011-01-04 05:39 skrev Dan McMahill: >> On 1/2/2011 12:37 AM, Ralf Wildenhues wrote: >>> Hi Dan, >>> >>> * Dan McMahill wrote on Sat, Jan 01, 2011 at 04:53:25AM CET: >>>> I am trying to build a program

Re: func_convert_file_cygwin_to_w32 woes

2011-01-03 Thread Dan McMahill
On 1/2/2011 12:37 AM, Ralf Wildenhues wrote: > Hi Dan, > > * Dan McMahill wrote on Sat, Jan 01, 2011 at 04:53:25AM CET: >> I am trying to build a program under cygwin but using the mingw tool >> chain in a fake cross build way. In my configure environment,

func_convert_file_cygwin_to_w32 woes

2010-12-31 Thread Dan McMahill
I am trying to build a program under cygwin but using the mingw tool chain in a fake cross build way. In my configure environment, I have: export lt_cv_to_tool_file_cmd=func_convert_file_cygwin_to_w32 as suggested by the libtool manual. I'm using libtool 2.4. Everything goes smoothly until in

Re: problems with LD_LIBRARY_PATH and libtool wrapper

2008-09-05 Thread Dan McMahill
Ralf Wildenhues wrote: and at configure time @LIBMINE_LDADD@ either gets set to ../libmine/libmine.la or something like -L/usr/pkg/lib -lmine. OK. First tangential issue: if you use @substitutions@ rather than Makefile.am conditionals, then automake cannot see through them, and you have to f

Re: problems with LD_LIBRARY_PATH and libtool wrapper

2008-09-05 Thread Dan McMahill
Ralf Wildenhues wrote: My analysis was at least partly wrong: * Ralf Wildenhues wrote on Thu, Aug 21, 2008 at 08:37:37AM CEST: * Dan McMahill wrote on Wed, Aug 20, 2008 at 03:55:19AM CEST: /bin/ksh ../libtool --tag=CC --mode=link gcc -g -O2 -Wall -Wl,-R/usr/pkg/lib -Wl,--rpath -Wl,/usr

Re: problems with LD_LIBRARY_PATH and libtool wrapper

2008-08-19 Thread Dan McMahill
Ralf Wildenhues wrote: Hi Dan, * Dan McMahill wrote on Wed, Aug 13, 2008 at 11:06:41PM CEST: I have a problem with the LD_LIBRARY_PATH handling inside of the libtool wrapper. I see a line like: # Add our own library path to LD_LIBRARY_PATH LD_LIBRARY_PATH="/usr/pkg/lib:/home/dan/src/m

Re: libtool wrapper env variable

2008-08-13 Thread Dan McMahill
Bruce Korb wrote: But this answer belongs in the other thread since it is not related to the question in this thread (which was how to set some arbitrary environment variable automatically in the libtool wrapper script). There isn't such a thing. If you fully link, then you don't need the "LD

Re: libtool wrapper env variable

2008-08-13 Thread Dan McMahill
Bruce Korb wrote: make LDFLAGS=-static You'll get a real binary, but statically incorporate libraries from the build tree. I guess this can be used for my question about LD_LIBRARY_PATH although it seems this problem will show up for lots of folks. Could this just be a problem with incorrec

problems with LD_LIBRARY_PATH and libtool wrapper

2008-08-13 Thread Dan McMahill
Hello, I have a problem with the LD_LIBRARY_PATH handling inside of the libtool wrapper. I see a line like: # Add our own library path to LD_LIBRARY_PATH LD_LIBRARY_PATH="/usr/pkg/lib:/home/dan/src/myprog/libmine/.libs:$LD_LIBRARY_PATH" in /home/dan/src/myprog/src/myprog which is the libtool

libtool wrapper env variable

2008-08-13 Thread Dan McMahill
Hello, I helped out with a a build system and switching to libtool for a shared library and am now having the following problem. After building but before installing, the program used to be able to be tested by cd foo-x.y/src ./myprog Unfortunately, myprog was keying off of the directory pa