Let a project use libtool to make libraries.
In case of mingw build (cross-compilation) in many cases is good dll to be
without lib prefix.
In these cases cross-compilation can create dlls with same names as native
build and those dlls can be used instead native build.
The name of import
(distributors) can decide how to create dlls.
Please comment,
Roumen
Roumen Petrov wrote:
Let a project use libtool to make libraries.
In case of mingw build (cross-compilation) in many cases is good dll
to be without lib prefix.
In these cases cross-compilation can create dlls with same names
Jason Curl wrote:
Roumen Petrov wrote:
[SNIP]
Well, I think I've figured it out today (albeit I'm testing on a
different machine, similar software though) and there are two
executables. One in the build directory and one in .libs. e.g.
src/
.libs/
libmofo-1.dll
test/
libtest.exe
Usually /etc/ld.so.conf contain /usr/local/lib.
Dunno why this path is not set on you host.
Benoit SIGOURE wrote:
Hi list,
On GNU/Linux Debian with GCC 4.1 / Debian's libtool 1.5.22-4
(1.1220.2.365 2005/12/18 22:14:06), I have Boost installed under
/usr/local/lib (pre-built binaries:
Russ Allbery wrote:
Simon White [EMAIL PROTECTED] writes:
However if one of those modules internally calls a function that is also
marked as being exported it does not necessarily call the function in
its own library. Depending on order it may call the function that
exists in the other
Ralf Wildenhues wrote:
* Daniel Herring wrote on Mon, Nov 12, 2007 at 07:46:55AM CET:
Here's a relevant post from the GCC list; it mentions how to work around
some dlopen difficulties (including RTTI, exceptions, custom new/delete).
http://gcc.gnu.org/ml/gcc-help/2007-10/msg00248.html
Simon Josefsson wrote:
Hi! We have received a bug report about some parts of recent gnutls
(libgnutls-extra.so.26) incorrectly links to the libgnutls.so in
/usr/lib/ rather than in $prefix, see original report:
http://lists.gnu.org/archive/html/gnutls-devel/2007-12/msg00038.html
To understand
Roumen Petrov wrote:
Daniel Sands wrote:
I have an executable that dlopens modules, and the modules make use of
symbols provided by the executable. Since AIX does not export symbols
unless either it has to (if needed for direct linkage to a shared
object) or you REALLY want it to (either
Alon Bar-Lev wrote:
On 3/15/08, Peter Rosin [EMAIL PROTECTED] wrote:
With your suggestion of always using age, you would get dll-7.dll and
dll-8.dll for your examples, but you would also get dll-7.dll for my
example, and then you would have the same file name for two incompatible
dlls, which
Erik de Castro Lopo wrote:
Hi all,
I have the beginnings of a solution to this issue.
If I hack the libtool generated wrapper script and replace this:
exec $progdir/$program ${1+$@}
with
WINEDLLPATH=$PATH;$WINEDLLPATH
exec wine $progdir/$program ${1+$@}
My test suite
Alon Bar-Lev wrote:
On 3/28/08, Peter O'Gorman [EMAIL PROTECTED] wrote:
-rpath is required for proper execution in many environments, the
ability to change the soname is, as far as I can tell, not.
Please present a more convincing argument.
Hello Peter,
I think that infrastructures such
Alon Bar-Lev wrote:
On 3/28/08, Roumen Petrov [EMAIL PROTECTED] wrote:
You request is to change library name. So I could not understand what is
related to SONAME. It came as a surprise to me to allow user(verdor) to
change library name at configure time.
It for generating a differnet
Alon Bar-Lev wrote:
On 3/29/08, Roumen Petrov [EMAIL PROTECTED] wrote:
So with automake makefile like this :
lib_LTLIBRARIES = @[EMAIL PROTECTED]
@[EMAIL PROTECTED] = module.c
@[EMAIL PROTECTED] = -module -avoid-version
where MODULE is substituted by configure you can get result.
Thanks
Hello libtool Team,
In my environment exist GNU C and Java compilers along with mingw C
cross-compiler. When I build libtool the path to mingw C-compiler (gcc)
precede path to native C-compiler.
In configure output I see :
checking for i386-mingw32msvc-strip... i386-mingw32msvc-strip
Bob Friesenhahn wrote:
On Fri, 9 May 2008, Roumen Petrov wrote:
checking for i386-mingw32msvc-gcj... no
checking for gcj... gcj - OOPS !
Is above detection correct ?
If is detected a prefix for a program why configure try to find a
program without prefix ?
It looks to me like
Ralf Wildenhues wrote:
Hello Roumen,
* Roumen Petrov wrote on Fri, May 09, 2008 at 09:39:11PM CEST:
In my environment exist GNU C and Java compilers along with mingw C
cross-compiler. When I build libtool the path to mingw C-compiler (gcc)
precede path to native C-compiler.
In configure
Vincent Torri wrote:
On Wed, 4 Jun 2008, Ralf Wildenhues wrote:
* Vikram Ambrose wrote on Wed, Jun 04, 2008 at 03:54:35PM CEST:
However I need to pass separate CPPFLAGS to the objects destined for the
shared library as opposed to the objects destined for the library
archive.
As Andreas
Alon Bar-Lev wrote:
Hello,
I looked at recent libtool-2 versions and could still not find a solution to
compile into chroot.
I want to create an image to embedded device using a cross compiler.
So I do:
mkdir /tmp/device-root
cd /package1
./configure --host= --prefix=/usr
make install
Bob Friesenhahn wrote:
On Thu, 12 Jun 2008, Alon Bar-Lev wrote:
After installing I want to perform:
chroot /tmp/device-root /bin/whatever
And continue from there.
So all elements (linkage, .la) should be related to the chroot and not
to host filesystem.
Why not just add a /tmp/device-root
Bernd Jendrissek wrote:
On Sat, Jun 14, 2008 at 9:59 AM, Alon Bar-Lev [EMAIL PROTECTED] wrote:
Building packages into chroot is more and more common, live-cd,
live-usb, initramfs, embedded, vservers etc...
A lot of packages use libtool, so using the standard gnu build for
chroot environment,
Jason Curl wrote:
Hello,
Recently some info was posted about using resource files with Windows
compilers. I'm trying to generate a reasonably simple Version resource and
there's some information I'm not sure how I can extract from the build process.
I'm using libtool-1.5.27a on MSYS-1.0.10
Vincent Torri wrote:
Hey,
Even if i'm still waiting for an answer about the func_win32_libid()
function, here is the 2nd problem:
On Sun, 5 Oct 2008, Ralf Wildenhues wrote:
2) 2nd qestion: I have the following message from libtool (which i do
not have with other compilers):
libtool:
Vincent Torri wrote:
On Tue, 7 Oct 2008, Roumen Petrov wrote:
Vincent Torri wrote:
Hey,
Even if i'm still waiting for an answer about the func_win32_libid()
function, here is the 2nd problem:
On Sun, 5 Oct 2008, Ralf Wildenhues wrote:
2) 2nd qestion: I have the following message from
Dan Nicholson wrote:
On Mon, Nov 3, 2008 at 2:05 PM, Ralf Wildenhues [EMAIL PROTECTED] wrote:
[SNIP]
Oh, well. You do know that all the linux distros (that I know of)
remove the .la files, right?
NO
I was sort of hoping there would be a
nice way to do that.
Check content of so called
Hi Russ,
Russ Allbery wrote:
Ralf Wildenhues [EMAIL PROTECTED] writes:
Hello Russ,
* Russ Allbery wrote on Fri, Nov 07, 2008 at 01:20:28AM CET:
The most frequent problem caused by *.la files is that they add a pile
of unnecessary dependencies to shared libraries, which further
entangles
Russ Allbery wrote:
Roumen Petrov [EMAIL PROTECTED] writes:
Russ Allbery wrote:
Debian's experience to date is that --as-needed is buggy and breaks a
lot of software, and overall is not a particularly stable solution.
Removing *.la files so that the unneeded shared libraries aren't linked
[SNIP]
But problem is not in the libtool.
Yes it is. If you're linking to libfoo, libtool reads libfoo.la and
adds direct links to everything in dependency_libs. Let's say libfoo
depends on libbar and libbaz. You're application ends up directly
linking to libfoo, libbar and libbaz instead of
Russ Allbery wrote:
Roumen Petrov [EMAIL PROTECTED] writes:
Russ Allbery wrote:
When you create a libtool library, libtool records every library
against which that library was linked into the *.la file. If you then
link another shared library against that shared library using libtool
Dan Nicholson wrote:
On Sat, Nov 8, 2008 at 9:22 AM, Roumen Petrov
[EMAIL PROTECTED] wrote:
[SNIP]
But problem is not in the libtool.
Yes it is. If you're linking to libfoo, libtool reads libfoo.la and
adds direct links to everything in dependency_libs. Let's say libfoo
depends on libbar
Russ Allbery wrote:
Roumen Petrov [EMAIL PROTECTED] writes:
It was old build bug when building readline library on some linux-es. In
my memory is suse 7.1 but I'm sure that only this particular version was
affected.
Many other linux verdors build readline without dependent libraries
Russ Allbery wrote:
Roumen Petrov [EMAIL PROTECTED] writes:
Russ Allbery wrote:
libreadline is linked against libncurses on Debian.
Which version ?
readline 5.2-3, ncurses 5.7-2.
No,no debian version/release.
This is an 7(5?) years old linux bug.
I'm very dubious
Vincent Torri wrote:
Hey,
Natively, the Windows CE OS has no concept of environment variable.
Hence, when mingw32ce is used, func_emit_cwrapperexe_src() fails because
of missing getenv() and putenv() (or setenv() also, of course). I don't
know what to do here (removing or not thee calls, as
Vincent Torri wrote:
Hey,
* Vincent Torri wrote on Tue, Oct 07, 2008 at 05:30:24PM CEST:
libtool call:
/bin/sh ../../libtool --tag=CC --mode=link arm-mingw32ce-gcc -g -O2
-Wl,--enable-auto-import -L/home/torri/local/wince/lib
-L/home/torri/local/opt/cegcc/lib -o suite.exe suite.o
Vincent Torri wrote:
On Sat, 6 Dec 2008, Roumen Petrov wrote:
You environment lack emulator, or winepath isn't in PATH.
WHY do I need an emulator ?
I need it to run the project tests including libtool tests.
I don't care about that. I just want my
executables being installed (copied
Jason Curl wrote:
Brian Dessent wrote:
Jason Curl wrote:
[SNIP]
I've attached a sample of the macros if there are comments.
e.g.
configure.ac (only the interesting bits)
[SNIP]
LX_PROG_RC
use AC_LIBTOOL_RC
AC_CONFIG_FILES([src/rsrc.rc])
Makefile.am
[SNIP]
.rc.lo:
$(LIBTOOL)
Jason Curl wrote:
Dan Nicholson wrote:
On Sat, Dec 13, 2008 at 12:57 AM, Jason Curl jcurln...@arcor.de wrote:
Ralf Wildenhues wrote:
[SNIP]
You're right, I only ran autoreconf. libtoolize fixed the problem.
A concern I have about libtoolize, it copies libtool.m4 and lt*.m4
files to my
Akim Demaille wrote:
Hi friends,
It's cold, the win32ter's back, and I'm a lonely winderer in the
winderful country to losedows.
As you suggested, I'm moved from pw32 to ming32, and as a result, I now
have a wrapper.exe instead of a shell script wrapper. This is
wonderful news, since I
Andy Wingo wrote:
Hi,
So, this is a resend, as for some reason the silliest of autotools
projects creates 300 kB tarballs. Attaching the files individually:
unpack in a directory of their own please.
***
Unpack the attached tarball (it will create its own directory). It is a
standard
LRN wrote:
I have a project that uses autoconf/automake/libtool, and it produces
shared libraries (on Windows that would be .dll) and static libraries
(.a). Which modifications are necessary for it to start outputing .lib
libraries (the ones that could be linked with link.exe) along with
.dll's?
LRN wrote:
OK, maybe it's a stupid question, but i have to ask anyway.
MinGW ships some static .a libraries. How do i link these to shared .dll
libraries? It seems that libtool always performs a check (filemagic in
my case) on each -lname argument, and to pass that check the library has
to be
Ralf Wildenhues wrote:
* Roumen Petrov wrote on Fri, Feb 27, 2009 at 10:07:19PM CET:
LRN wrote:
OK, maybe it's a stupid question, but i have to ask anyway.
MinGW ships some static .a libraries. How do i link these to shared .dll
libraries? It seems that libtool always performs a check
Ralf Wildenhues wrote:
Hello Vincent, Bob,
[SNIP]
But anyway, I don't see how the current git code generates C wrappers
for wince.
The host is usually xxx-mingw32ce and will match patterns like
{*-}*-mingw*, i.e. it will generate wrappers as for mingw32.
But the C-wrapper-code of
Vincent Torri wrote:
Hey,
I'm writing a dll using D3D and autotools stuff (MSYS / MinGW). I pass
-ld3dx9 and i have added everything so that the dll is built.
If I add from the DirectX SDK d3dx9.lib in /mingw/lib, i have the usual
warning message from linker / libtool:
*** Warning:
Eric Blake wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Jan Engelhardt on 7/24/2009 3:25 AM:
Hi,
when one has a program that does something like
if(strcmp(argv[0], gunzip) == 0)
uncompress();
else
compress();
GNU Coding Standards frown on this practice:
Ralf Wildenhues wrote:
* Joakim Tjernlund wrote on Thu, Dec 10, 2009 at 08:04:27AM CET:
Ralf Wildenhues wrote on 10/12/2009 06:16:40:
* Joakim Tjernlund wrote on Thu, Dec 10, 2009 at 12:50:14AM CET:
Ralf Wildenhues wrote on 08/12/2009 20:13:13:
./configure --prefix=/opt/x/y
make
Hi libtool webadmin,
This page http://www.gnu.org/software/libtool/ currently refer to site
http://mail.gnu.org/;... for libtool related mail lists . It seems to
that correct site is http://lists.gnu.org/...;.
Also not all links point to final location as example
Hi Ralf,
Ralf Wildenhues wrote:
Hi Roumen,
* Roumen Petrov wrote on Sat, Jan 09, 2010 at 04:33:00PM CET:
This page http://www.gnu.org/software/libtool/ currently refer to
site http://mail.gnu.org/;... for libtool related mail lists . It
seems to that correct site is http://lists.gnu.org
Kuang-Chun Cheng wrote:
Hi,
I'm using mingw cross compiler (with GNU autotools) under Linux to build DLL.
One of the package I build is gnet2-2.0.8 which will link winsock library.
Everything is OK, the DLL is created under Linux.
When I copy the library to WinXP and use gnet2-2.0.8 to create
Matěj Týč wrote:
On Tue, 2010-01-26 at 23:26 +0800, JonY wrote:
...
I suggest the following naming scheme.
mingw.org: libname-major.dll (unchanged)
Cygwin: cygname-major.dll (unchanged)
mingw-w64(64): lib64name-major.dll
mingw-w64(32): lib32name-major.dll
libtool should also
Matěj Týč wrote:
[SNIP]
Wow, this is interesting.
I remember that one guy asked about the dll prefix and he has been
advised to strip the prefix from the library name and add the '-module'
flag to libtool in order to silence complaints.
[SNIP]
-module flag will install dll in $libdir and
I don't understand request as the usually final result is
.../libfool.la
.../libfool.dll.a
.../libfool.dll
.../libfool.a
Also note that makefiles the macros(variables) are libfoo_.
Did the requester expect if target is libfoo_ make command to search
for libYYfoo_ or may be
JonY wrote:
On 1/31/2010 02:14, Roumen Petrov wrote:
I don't understand request as the usually final result is
.../libfool.la
.../libfool.dll.a
.../libfool.dll
.../libfool.a
Also note that makefiles the macros(variables) are libfoo_.
Did the requester expect if target is libfoo_ make
Gary V. Vaughan wrote:
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, portable interface.
The Libtool Team is
Gary V. Vaughan wrote:
Hi Roumen,
On 22 May 2010, at 03:26, Roumen Petrov wrote:
Gary V. Vaughan wrote:
The Libtool Team is pleased to announce release candidate 2.2.7b of GNU
Libtool. If there are no serious deficiencies reported in this release,
it will be renumbered as 2.2.8 and re
Hello All,
I wonder how to build and test on a 64 bit platform a 32 bit libtool
version.
First test is to use --build=x86_64-gnu-linux --host=i386-gnu-linux with
CC and CXX set to 'gcc|g++ -m32', i.e. multilib .
The libtool regression suite fail in test case :
25: duplicate convenience
Hi Andreas and Bo,
Please could you clarify build of 64-bit system for 32 bit.
Roumen Petrov wrote:
Hello All,
I wonder how to build and test on a 64 bit platform a 32 bit libtool
version.
First test is to use --build=x86_64-gnu-linux --host=i386-gnu-linux
with CC and CXX set to 'gcc|g
Hi Gary,
Gary V. Vaughan wrote:
Hi Chuck,
I note that no other GNU projects that I'm aware of jump through all the
__declspec hoops that the libltdl API tries to provide through LT_SCOPE.
Is any of this stuff still required on any non-museum Windows compiler
that would break if I removed it?
Hello Gary,
After monster updates in repository please could you help me to
bootstrap libtool.
I don't like to create symbolic links, so I use --copy argument , but
since 2011-11-08 it does not work.
The command is
./bootstrap \
--copy \
--force \
--gnulib-srcdir=
Sam Varshavchik wrote:
My source tree builds two libraries, from two separate directories in
the source tree.
libxtls.la gets linked against libx.la in a different directory, as
well as some system libraries in /usr/local/lib. Makefile.am declares
thusly:
libxtls_la_LIBADD=../base/libx.la
lt_cv_sys_lib_dlsearch_path_spec to override it at
configure time.
.../configure \
...
lt_cv_sys_lib_dlsearch_path_spec=ORIGINAL VALUE STAGING_PATH
...
Regards
Roumen Petrov
___
https://lists.gnu.org/mailman/listinfo/libtool
Werner LEMBERG wrote:
Folks,
my ttfautohint library exports a single function (`TTF_autohint') and
depends on freetype and harfbuzz. A user posted the following recipe
to merge these three libraries into a single DLL in Windows.
Looks like use of libtool "Convenience" libraries.
[SNIP]
" script(s) will
be generated in build tree.
Regards,
Roumen Petrov
___
https://lists.gnu.org/mailman/listinfo/libtool
e function that does this is only
used in rather exotic corner-cases (old dlltool and/or ms dumpbin being in
use), so it's plausible that it could have been broken since 2010, when it was
added.
Regards,
Roumen Petrov
___
https://lists.gnu.org/mailma
e autoconf builds with use of libtool you could force -rpath if
needed - add those options to LDFLAGS ( see ./configure --help) .
Regards,
Roumen Petrov
___
https://lists.gnu.org/mailman/listinfo/libtool
Yuri wrote:
On 2019-06-23 12:19, Roumen Petrov wrote:
cc ?
I'm not sure which compiler suite is used on FreeBSD but it seems to
me C++ compiler is not installed.
clang8 is used. cc is a C compiler, c++ is a C++ compiler.
Ok. Dunno why is not detected c++ at configure time. I'm
Yuri wrote:
On FreeBSD libtool can't find operator new[] because it is in C mode:
libtool: link: cc -fno-strict-aliasing -fopenmp -ftree-vectorize
-pthread -O2 -pipe -fno-omit-frame-pointer -fstack-protector-strong
-fno-strict-aliasing -fno-strict-aliasing -fstack-protector-strong -o
Dunno what is wrong in Yuri's FreeBSD environment
Bob Friesenhahn wrote:
On Sun, 23 Jun 2019, Yuri wrote:
So is there an easy way to override this and always use C++ way of
linking?
To do this you might need to set LD or CC to your C++ compiler. A
better way is to make your main program
uri wrote:
> On 2019-06-24 09:55, Roumen Petrov wrote:
>>
>> And projects builds just fine!
>> Conclusion - there is no defect neither in libtool nor in automake nor
>> in project autotool files.
>>
>> Reporter still does not provide feedback with informatio
regression tests should use library from
"build tree" not system one.
Regards,
Roumen Petrov
___
https://lists.gnu.org/mailman/listinfo/libtool
Martin Liška wrote:
[SNIP]
However, LTO breaks nm really badly and with -fno-common this variable
gets marked as "T" in the nm output.
Thank you for identification of the root cause. I've just created a
nm issue
for that:
https://sourceware.org/bugzilla/show_bug.cgi?id=25355
It is clear
question is how to remove some extra dependencies :
automatically (--as-needed) or manually (using tools like patchelf).
May be topic is not for libtool list.
Regards,
Roumen Petrov
Hi Russ, libtool members,
I work on open source projects in my spare time. And so I can not
provide feedback promptly. Today I have time to re read mail thread and
to clarify my strong position.
Russ Allbery wrote:
Roumen Petrov writes:
Urgh, article with very limited niche. First
e?
Not reproducible with FSF release.
Regards,
Roumen Petrov
: [/tmp/translib/lib]
Regards,
Roumen Petrov
Hello,
wf...@niif.hu wrote:
Roumen Petrov writes:
wf...@niif.hu wrote:
I'm experimenting with the attached skeleton project on a Debian buster
Debian is key word.
system (autoconf 2.69-11, automake 1:1.16.1-4 and libtool 2.4.6-9):
Libtool is patched, not FSF.
[SNIP]
/usr/bin/ld
ne solution would be : never compile 'lbfoo' as a static lib ("DLL
are good on Windows"), but I would like to support both static and
shared libraries.
Does someone know how to solve my issue ? (I hope I've been clear enough...)
thank you
Vincent Torri
Regards,
Roumen Petrov
nvironment
on Linux.
I cannot understand why wine in installed but not properly setup. Either remove
wine or finish installation.
Regards
Roumen Petrov
Hi ilya,
ilya Basin wrote:
Hi List.
I'm making a program with plugins as shared libraries and when I run `make
check` I want my program to load the uninstalled plugins using lt_dlopen().
I expected that passing `-dlopen libname.la` to libtool would force the generation of a wrapper script
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
ems to me more users will test release version then beta or release
candidate.
[SNIP]
Regards,
Roumen Petrov
nu.org/cgi/bugreport.cgi?bug=53479
If those bugs are not Debian specific someone could look at them.
Libtool projects must not care for defects that shows Debian libtool brokenness.
Regards,
Roumen Petrov
Hi Raúl,
I would like to know if option SH_WORD_SPLIT is set problem is solved too ?
Test case:
===
#!/bin/zsh
VAR=v1 v2
for V in ${VAR}; do
echo V1=$V
done
setopt SH_WORD_SPLIT
for V in ${VAR}; do
echo V2=$V
done
===
When
Bruno Haible wrote:
Hi,
A while ago someone said that if in a build directory I have a (not yet
installed) ../lib/libfoo.la, to link with this library I should *not* use
libtool ... -L../lib -lfoo
but rather mention the .la file explicitly:
libtool ... -L../lib ../lib/libfoo.la
or
Roumen Petrov wrote:
Ralf Wildenhues wrote:
* Roumen Petrov wrote on Sun, Mar 09, 2008 at 05:01:30PM CET:
[SNIP]
Hmm during the tests tests/demo/helldl.exe is compiled many times.
First is ok, later don't produce output(exit code 127) and
tests/demo/.libs/helldl.exe crash.
Roumen
Behdad Esfahbod wrote:
On Tue, 2006-06-13 at 17:00 -0400, Ralf Wildenhues wrote:
[ this is: http://thread.gmane.org/gmane.comp.gnu.libtool.bugs/5319
or http://lists.gnu.org/archive/html/bug-libtool/2006-03/msg00013.html ]
Hi Behdad, everyone,
Hi again,
Sorry for the delay again.
So,
Behdad Esfahbod wrote:
On Thu, 2008-04-17 at 23:38 +0300, Roumen Petrov wrote:
I think that all above is out of libtool scope.
It's is exceptional project specific (lets skip cross-compilation
environment) and is subject of project regression test suite.
The project is responsible to set
Behdad Esfahbod wrote:
[SNIP]
But if user run directly an application installed in non-default
location the user is responsible to set environment.
I'm not talking about application installed in non-default location.
I'm talking about uninstalled application.
There is no significant
Behdad Esfahbod wrote:
On Fri, 2008-04-18 at 02:32 +0300, Roumen Petrov wrote:
Behdad Esfahbod wrote:
[SNIP]
But if user run directly an application installed in non-default
location the user is responsible to set environment.
I'm not talking about application installed in non-default
Behdad Esfahbod wrote:
On Fri, 2008-04-18 at 21:53 +0300, Roumen Petrov wrote:
In some cases application depend from other services.
In this case a specific to project wrapper script has to run
services,
to check if service is run, to run project application and when
application finish
Ralf Wildenhues wrote:
* Bob Friesenhahn wrote on Fri, Apr 18, 2008 at 09:15:55PM CEST:
The only substantial change is for static builds which currently
don't have a wrapper.
Yes.
The static build is a more significant concern since static builds are
often used for debugging purposes and if
Behdad Esfahbod wrote:
On Fri, 2008-04-18 at 22:27 +0300, Roumen Petrov wrote:
I perfectly know that user
cannot go in build-dir and just to run secure shell daemon/client.
And if you are happy with that, good for you.
:)
In GNOME
Ohh no
though, we want
our users to be able to run
Hi Charles,
About following comment:
/* execv doesn't actually work on mingw as expected on unix */
Actually execXXX on microsoft windows create a new process and it is not
mingw problem. What about to substitute mingw with windows ?
Roumen
Charles Wilson wrote:
Charles Wilson wrote:
Charles Wilson wrote:
Charles Wilson wrote:
2008-05-05 Charles Wilson ...
* libltdl/config/ltmain.m4sh (func_to_native_path):
new function. If $host is mingw, and $build is mingw
or cygwin, convert path to mingw native format.
(func_to_native_pathlist): new function. Ditto,
Charles Wilson wrote:
Roumen Petrov wrote:
libtool 2.2.4 patched with both patches still fail:
...
(lt_setenv) setting 'PATH' to
':/usr/local/src//lt-2.2.4-mingw-mlib/lib2/.libs:/usr/local/src//lt-2.2.4-mingw-mlib/lib1/.libs:/tmp/test/pkg/lt-2.2.4-mingw-mlib/lib:/tmp/test/pkg
Charles Wilson wrote:
[mingw] Add cross-compile support to cwrapper
* libltdl/config/ltmain.m4sh (func_to_host_path):
If present, use winepath to convert from $build to $host
if $host is mingw and $build is neither mingw (msys) nor
cygwin. Also update comments.
(func_to_host_pathlist): Ditto.
Charles Wilson wrote:
Roumen Petrov wrote:
Charles Wilson wrote:
[mingw] Add cross-compile support to cwrapper
May be the patch can be more simple. In a previous post I confirm that
for the wine emulator is enough items in path list, where every item
is absolute path from build system
No answer from wine-developers (
http://www.winehq.org/pipermail/wine-devel/2008-May/065695.html )
As expected you patch pass my test :). Lets go upstream.
Roumen
Roumen Petrov wrote:
Charles Wilson wrote:
Roumen Petrov wrote:
Charles Wilson wrote:
[mingw] Add cross-compile support
Charles Wilson wrote:
Roumen Petrov wrote:
No answer from wine-developers (
http://www.winehq.org/pipermail/wine-devel/2008-May/065695.html )
As expected you patch pass my test :).
That's good to know. Except for one issue [1], I'm of the opinion that
my current patch is pedantically
Charles Wilson wrote:
Roumen Petrov wrote:
[SNIP]
Try replacing the section above with:
* )
# Unfortunately, winepath does not exit with a non-zero
# error code, so we are forced to check the contents of
# stdout. On the other hand, if the command
Charles Wilson wrote:
Roumen Petrov wrote:
# func_to_host_path arg
[SNIP]
# ARG is the path (on $build) that should be converted to
# the proper representation for $host. The result is stored
@@ -2546,11 +2553,28 @@ func_to_host_path ()
func_to_host_path_result=`echo
1 - 100 of 155 matches
Mail list logo
