From: Lorenzo B. <be...@ds...> - 2009-02-22 19:22:11
|
When compiling a program that uses fopen and run it from msys, it fails to open files such as /usr/local/share/foo.lang /home/myself/foo.lang although the files are there (and I can see them with less from the msys shell)... it suceeds to open them only when using the paths c:/msys/1.0/local/share/foo.lang c:/msys/1.0/home/myself/foo.lang is this the intended behavior? thanks in advance Lorenzo -- Lorenzo Bettini, PhD in Computer Science, DI, Univ. Torino ICQ# lbetto, 16080134 (GNU/Linux User # 158233) HOME: http://www.lorenzobettini.it MUSIC: http://www.purplesucker.com http://www.myspace.com/supertrouperabba BLOGS: http://tronprog.blogspot.com http://longlivemusic.blogspot.com http://www.gnu.org/software/src-highlite http://www.gnu.org/software/gengetopt http://www.gnu.org/software/gengen http://doublecpp.sourceforge.net |
From: Tor L. <tm...@ik...> - 2009-02-22 19:29:25
|
> is this the intended behavior? Yes. --tml |
From: Earnie B. <ea...@us...> - 2009-02-23 12:48:55
|
Quoting Lorenzo Bettini <be...@ds...>: > When compiling a program that uses fopen and run it from msys, it fails > to open files such as > > /usr/local/share/foo.lang > /home/myself/foo.lang > > although the files are there (and I can see them with less from the msys > shell)... it suceeds to open them only when using the paths > > c:/msys/1.0/local/share/foo.lang > c:/msys/1.0/home/myself/foo.lang > > is this the intended behavior? > You haven't given enough to say whether what you perceive is correct or not. If the path is being passed to the program from the shell on the command line then MSYS should convert it for you. If the path is being passed to fopen hardcoded in the source then yes, it is the correct behavior. MSYS has no idea what fopen is doing; that belongs to the MSVCRT runtime. Earnie |
From: Lorenzo B. <be...@ds...> - 2009-02-26 09:10:11
|
Earnie Boyd wrote: > Quoting Lorenzo Bettini <be...@ds...>: > >> When compiling a program that uses fopen and run it from msys, it fails >> to open files such as >> >> /usr/local/share/foo.lang >> /home/myself/foo.lang >> >> although the files are there (and I can see them with less from the msys >> shell)... it suceeds to open them only when using the paths >> >> c:/msys/1.0/local/share/foo.lang >> c:/msys/1.0/home/myself/foo.lang >> >> is this the intended behavior? >> > > You haven't given enough to say whether what you perceive is correct or > not. If the path is being passed to the program from the shell on the > command line then MSYS should convert it for you. If the path is being > passed to fopen hardcoded in the source then yes, it is the correct > behavior. MSYS has no idea what fopen is doing; that belongs to the > MSVCRT runtime. > yes, I was actually talking about an hardcoded path, which in turn is retrieved directly from the configure script (the $prefix value); since configure defaults to /usr/local as a prefix, this technique basically does not work correctly in this environment -- Lorenzo Bettini, PhD in Computer Science, DI, Univ. Torino ICQ# lbetto, 16080134 (GNU/Linux User # 158233) HOME: http://www.lorenzobettini.it MUSIC: http://www.purplesucker.com http://www.myspace.com/supertrouperabba BLOGS: http://tronprog.blogspot.com http://longlivemusic.blogspot.com http://www.gnu.org/software/src-highlite http://www.gnu.org/software/gengetopt http://www.gnu.org/software/gengen http://doublecpp.sourceforge.net |
From: Earnie B. <ea...@us...> - 2009-02-26 13:42:10
|
Quoting Lorenzo Bettini <be...@ds...>: > > yes, I was actually talking about an hardcoded path, which in turn is > retrieved directly from the configure script (the $prefix value); since > configure defaults to /usr/local as a prefix, this technique basically > does not work correctly in this environment > The remedy is simple: --prefix=`cd /usr/local; pwd -W` You might want to use your mingw path instead of /usr/local so GCC can find the libraries without needing to tell it. Giving the prefix as I have given you will cause the paths in configure to become windows absolute paths with forward slash (/) delimiters. Earnie |
From: Keith M. <kei...@us...> - 2009-02-26 22:06:16
|
On Thursday 26 February 2009 12:04:41 Earnie Boyd wrote: > > since > > configure defaults to /usr/local as a prefix, this technique > > basically does not work correctly in this environment > > The remedy is simple: > > --prefix=`cd /usr/local; pwd -W` > > You might want to use your mingw path instead of /usr/local so GCC > can find the libraries without needing to tell it. Unless, of course, you've followed the instructions at: http://www.mingw.org/wiki/SpecsFileHOWTO and configured GCC so that it *does* know how to locate /usr/local. In that case, you can create a config.site file, (see autoconf.info section 14.7), including the assignment: ac_default_prefix=`cd /usr/local; pwd -W` so that configure scripts *will* use the windows path by default; (otherwise, you can specify: ac_default_prefix=`cd /mingw; pwd -W` to use the default MinGW windows path). -- Regards, Keith. |
From: Lorenzo B. <be...@ds...> - 2009-02-27 09:31:35
|
Keith Marshall wrote: > On Thursday 26 February 2009 12:04:41 Earnie Boyd wrote: >>> since >>> configure defaults to /usr/local as a prefix, this technique >>> basically does not work correctly in this environment >> The remedy is simple: >> >> --prefix=`cd /usr/local; pwd -W` >> >> You might want to use your mingw path instead of /usr/local so GCC >> can find the libraries without needing to tell it. > > Unless, of course, you've followed the instructions at: > http://www.mingw.org/wiki/SpecsFileHOWTO > > and configured GCC so that it *does* know how to locate /usr/local. > In that case, you can create a config.site file, (see autoconf.info > section 14.7), including the assignment: > > ac_default_prefix=`cd /usr/local; pwd -W` > > so that configure scripts *will* use the windows path by default; this looks like the best solution: if a user simply runs ./configure everything will work fine with the default prefix on every platform, I guess, right? however, for instance, under Linux pwd does not support -W > (otherwise, you can specify: > > ac_default_prefix=`cd /mingw; pwd -W` > > to use the default MinGW windows path). for the moment I've passed /mingw to --prefix configure option. -- Lorenzo Bettini, PhD in Computer Science, DI, Univ. Torino ICQ# lbetto, 16080134 (GNU/Linux User # 158233) HOME: http://www.lorenzobettini.it MUSIC: http://www.purplesucker.com http://www.myspace.com/supertrouperabba BLOGS: http://tronprog.blogspot.com http://longlivemusic.blogspot.com http://www.gnu.org/software/src-highlite http://www.gnu.org/software/gengetopt http://www.gnu.org/software/gengen http://doublecpp.sourceforge.net |
From: Earnie B. <ea...@us...> - 2009-02-27 12:21:16
|
Quoting Lorenzo Bettini <be...@ds...>: > > however, for instance, under Linux pwd does not support -W > The last I knew (years ago) Cygwin doesn't support it either. It is a MSYS specific add on to provide the Windows absolute path for those times when you just have to have it. Earnie |
From: Keith M. <kei...@us...> - 2009-02-27 22:26:06
|
On Friday 27 February 2009 09:31:14 Lorenzo Bettini wrote: > > ... you can create a config.site file, (see > > autoconf.info section 14.7), including the assignment: > > > > ac_default_prefix=`cd /usr/local; pwd -W` > > > > so that configure scripts *will* use the windows path by default; > > this looks like the best solution: if a user simply runs > ./configure everything will work fine with the default prefix on > every platform, I guess, right? Yes. > however, for instance, under Linux pwd does not support -W No, it doesn't; this feature is specific to MSYS. However, the config.site you implement is also specific, in this case to *your* MSYS installation -- you don't distribute it. You implement this for your own use, so that when *you* run any autoconf generated configure script, within *your* MSYS environment, the default prefix is set to your preferred local installation path, appropriately defined using MS-Windows semantics, without any need to specify it explicitly. -- Regards, Keith. |
From: Lorenzo B. <be...@ds...> - 2009-03-01 18:59:52
|
Keith Marshall wrote: > On Friday 27 February 2009 09:31:14 Lorenzo Bettini wrote: >>> ... you can create a config.site file, (see >>> autoconf.info section 14.7), including the assignment: >>> >>> ac_default_prefix=`cd /usr/local; pwd -W` >>> >>> so that configure scripts *will* use the windows path by default; >> this looks like the best solution: if a user simply runs >> ./configure everything will work fine with the default prefix on >> every platform, I guess, right? > > Yes. > >> however, for instance, under Linux pwd does not support -W > > No, it doesn't; this feature is specific to MSYS. However, the > config.site you implement is also specific, in this case to *your* > MSYS installation -- you don't distribute it. You implement this for > your own use, so that when *you* run any autoconf generated configure > script, within *your* MSYS environment, the default prefix is set to > your preferred local installation path, appropriately defined using > MS-Windows semantics, without any need to specify it explicitly. > mh... so this does not help: for my own use I know what to do, while I'm worried about the user who's installing my programs (also in msys) and expects that with default values everything works fine, while it won't... -- Lorenzo Bettini, PhD in Computer Science, DI, Univ. Torino ICQ# lbetto, 16080134 (GNU/Linux User # 158233) HOME: http://www.lorenzobettini.it MUSIC: http://www.purplesucker.com http://www.myspace.com/supertrouperabba BLOGS: http://tronprog.blogspot.com http://longlivemusic.blogspot.com http://www.gnu.org/software/src-highlite http://www.gnu.org/software/gengetopt http://www.gnu.org/software/gengen http://doublecpp.sourceforge.net |
From: Earnie B. <ea...@us...> - 2009-03-02 12:32:15
|
Quoting Lorenzo Bettini <be...@ds...>: > Keith Marshall wrote: >> On Friday 27 February 2009 09:31:14 Lorenzo Bettini wrote: >>>> ... you can create a config.site file, (see >>>> autoconf.info section 14.7), including the assignment: >>>> >>>> ac_default_prefix=`cd /usr/local; pwd -W` >>>> >>>> so that configure scripts *will* use the windows path by default; >>> this looks like the best solution: if a user simply runs >>> ./configure everything will work fine with the default prefix on >>> every platform, I guess, right? >> >> Yes. >> >>> however, for instance, under Linux pwd does not support -W >> >> No, it doesn't; this feature is specific to MSYS. However, the >> config.site you implement is also specific, in this case to *your* >> MSYS installation -- you don't distribute it. You implement this for >> your own use, so that when *you* run any autoconf generated configure >> script, within *your* MSYS environment, the default prefix is set to >> your preferred local installation path, appropriately defined using >> MS-Windows semantics, without any need to specify it explicitly. >> > > mh... so this does not help: for my own use I know what to do, while I'm > worried about the user who's installing my programs (also in msys) and > expects that with default values everything works fine, while it won't... > Why wouldn't your program work fine for others if the configure inserts an absolute windows path for the defined macro? You're program doesn't have a dependency to config.site only autoconf's configure does. Earnie |
From: Lorenzo B. <be...@ds...> - 2009-03-02 19:55:13
|
Earnie Boyd wrote: > Quoting Lorenzo Bettini <be...@ds...>: > >> Keith Marshall wrote: >>> On Friday 27 February 2009 09:31:14 Lorenzo Bettini wrote: >>>>> ... you can create a config.site file, (see >>>>> autoconf.info section 14.7), including the assignment: >>>>> >>>>> ac_default_prefix=`cd /usr/local; pwd -W` >>>>> >>>>> so that configure scripts *will* use the windows path by default; >>>> this looks like the best solution: if a user simply runs >>>> ./configure everything will work fine with the default prefix on >>>> every platform, I guess, right? >>> Yes. >>> >>>> however, for instance, under Linux pwd does not support -W >>> No, it doesn't; this feature is specific to MSYS. However, the >>> config.site you implement is also specific, in this case to *your* >>> MSYS installation -- you don't distribute it. You implement this for >>> your own use, so that when *you* run any autoconf generated configure >>> script, within *your* MSYS environment, the default prefix is set to >>> your preferred local installation path, appropriately defined using >>> MS-Windows semantics, without any need to specify it explicitly. >>> >> mh... so this does not help: for my own use I know what to do, while I'm >> worried about the user who's installing my programs (also in msys) and >> expects that with default values everything works fine, while it won't... >> > > Why wouldn't your program work fine for others if the configure inserts > an absolute windows path for the defined macro? You're program doesn't > have a dependency to config.site only autoconf's configure does. yes, but how to use a windows path? If pwd -W is not standard? -- Lorenzo Bettini, PhD in Computer Science, DI, Univ. Torino ICQ# lbetto, 16080134 (GNU/Linux User # 158233) HOME: http://www.lorenzobettini.it MUSIC: http://www.purplesucker.com http://www.myspace.com/supertrouperabba BLOGS: http://tronprog.blogspot.com http://longlivemusic.blogspot.com http://www.gnu.org/software/src-highlite http://www.gnu.org/software/gengetopt http://www.gnu.org/software/gengen http://doublecpp.sourceforge.net |
From: Earnie B. <ea...@us...> - 2009-03-02 20:56:12
|
Quoting Lorenzo Bettini <be...@ds...>: > > yes, but how to use a windows path? If pwd -W is not standard? > I don't understand our disconnection. The -W is MSYS specific. If one is using MSYS then pwd -W is available. If one uses Cygwin they use cygpath or something like that. If one uses some other shell, they use whatever else is available. How does this affect your program? I suspect you might want to consider the location of the installed path and use relative paths to walk up the tree to find the path. If you use relative pathing if a program is installed in c:/msys/1.0/usr/local/bin then one should be able to find c:/msys/1.0/user/local/lib by using ../lib instead. This way your program can be installed on /some/path/noone/knows/the/name/to and it still is likely to work. This is what GCC does to find it's lib and include paths. Earnie |
From: Lorenzo B. <be...@ds...> - 2009-03-06 09:20:18
|
Tor Lillqvist wrote: >>> GetModuleFileName() is your friend. > >> but it's not in the standard library, so it is not a portable solution... > > Get real. What you asked for can (by definition, almost) not be done > in a "portable" way if you mean some code that would work on all > platforms, or even just Windows and Linux. Of course you will have to > use ifdefs. You mean that gcc does like that for determining its own path? -- Lorenzo Bettini, PhD in Computer Science, DI, Univ. Torino ICQ# lbetto, 16080134 (GNU/Linux User # 158233) HOME: http://www.lorenzobettini.it MUSIC: http://www.purplesucker.com http://www.myspace.com/supertrouperabba BLOGS: http://tronprog.blogspot.com http://longlivemusic.blogspot.com http://www.gnu.org/software/src-highlite http://www.gnu.org/software/gengetopt http://www.gnu.org/software/gengen http://doublecpp.sourceforge.net |
From: Lorenzo B. <be...@ds...> - 2009-03-03 08:22:02
|
Earnie Boyd wrote: > Quoting Lorenzo Bettini <be...@ds...>: > >> yes, but how to use a windows path? If pwd -W is not standard? >> > > I don't understand our disconnection. The -W is MSYS specific. If one > is using MSYS then pwd -W is available. If one uses Cygwin they use > cygpath or something like that. If one uses some other shell, they use > whatever else is available. How does this affect your program? > > I suspect you might want to consider the location of the installed path > and use relative paths to walk up the tree to find the path. If you > use relative pathing if a program is installed in > c:/msys/1.0/usr/local/bin then one should be able to find > c:/msys/1.0/user/local/lib by using ../lib instead. This way your > program can be installed on /some/path/noone/knows/the/name/to and it > still is likely to work. This is what GCC does to find it's lib and > include paths. the problem is configure script defaults $prefix to /usr/local. How can you make sure that any user downloads my program and by simply running configure it will build a working program, i.e., one where the hardcoded path works? This package builds a library, where the $prefix is hardcoded; how can this library use relative paths? It must start from a hardcoded one? -- Lorenzo Bettini, PhD in Computer Science, DI, Univ. Torino ICQ# lbetto, 16080134 (GNU/Linux User # 158233) HOME: http://www.lorenzobettini.it MUSIC: http://www.purplesucker.com http://www.myspace.com/supertrouperabba BLOGS: http://tronprog.blogspot.com http://longlivemusic.blogspot.com http://www.gnu.org/software/src-highlite http://www.gnu.org/software/gengetopt http://www.gnu.org/software/gengen http://doublecpp.sourceforge.net |
From: Earnie B. <ea...@us...> - 2009-03-03 12:24:34
|
Quoting Lorenzo Bettini <be...@ds...>: > > the problem is configure script defaults $prefix to /usr/local. How can > you make sure that any user downloads my program and by simply running > configure it will build a working program, i.e., one where the hardcoded > path works? This package builds a library, where the $prefix is > hardcoded; how can this library use relative paths? It must start from > a hardcoded one? > The onus belongs to the executor of configure to follow the directions. You can't guard against the idiots that don't follow the directions. You determine the relative path based on the location of the executing binary or dll. I do this for MSYS. GCC does it for finding its libraries. Functions exist to return where the binary executes from. Earnie |
From: Lorenzo B. <be...@ds...> - 2009-03-08 14:07:59
|
Tor Lillqvist wrote: >> You mean that gcc does like that for determining its own path? > > It could, but it doesn't. As far as I could see gcc instead seems to > rely on argv[0] containing a full path to the gcc executable, or if > that is not the case, the executable being present in PATH. This of > course usually works fine, too. > > But note that you said "also for libraries". (Presumably meaning > *shared* libraries.) For a shared library to find out where it is > located there is no argv[0] to use. You must use ifdefs as the name of > a shared library file is different on different platforms, and the > environment variable that tells where to search for shared libraries > is different (PATH, LD_LIBRARY_PATH, SHLIB_PATH, DYLD_PATH, others?). > > Also, actually you of course can't be sure that the library was found > using such an environment variable directed mechanism. It might have > been found in a system-dependent standard location (%WINDIR%/system32, > %WINDIR%, the current directory, the folder where the .exe is, > /usr/lib, /usr/lib64, etc) or have been loaded using an explicit path > either programmatically or by the executable file format specifying an > explicit path or additional search path. And as you need ifdefs > anyway, why not just then in the case of Windows use the simple > DllMain() (to save the DLL handle) and GetModuleFileName() method. OK, then we're back to hardcode the path where the library (since from what I read above, there's no easy and reliable way to detect the right path) will be installed, and back to my problem that the path /usr/local will not work for fopen... -- Lorenzo Bettini, PhD in Computer Science, DI, Univ. Torino ICQ# lbetto, 16080134 (GNU/Linux User # 158233) HOME: http://www.lorenzobettini.it MUSIC: http://www.purplesucker.com http://www.myspace.com/supertrouperabba BLOGS: http://tronprog.blogspot.com http://longlivemusic.blogspot.com http://www.gnu.org/software/src-highlite http://www.gnu.org/software/gengetopt http://www.gnu.org/software/gengen http://doublecpp.sourceforge.net |
From: Lorenzo B. <be...@ds...> - 2009-03-03 14:12:49
|
Earnie Boyd wrote: > Quoting Lorenzo Bettini <be...@ds...>: > >> the problem is configure script defaults $prefix to /usr/local. How can >> you make sure that any user downloads my program and by simply running >> configure it will build a working program, i.e., one where the hardcoded >> path works? This package builds a library, where the $prefix is >> hardcoded; how can this library use relative paths? It must start from >> a hardcoded one? >> > > The onus belongs to the executor of configure to follow the directions. > You can't guard against the idiots that don't follow the directions. mh... I don't think that's the case since we're talking about the default configuration... > > You determine the relative path based on the location of the executing > binary or dll. I do this for MSYS. GCC does it for finding its > libraries. Functions exist to return where the binary executes from. OK, any suggestion about this? I mean, how to find the location of the executing binary from with the program itself? And also for libraries? thanks in advance Lorenzo -- Lorenzo Bettini, PhD in Computer Science, DI, Univ. Torino ICQ# lbetto, 16080134 (GNU/Linux User # 158233) HOME: http://www.lorenzobettini.it MUSIC: http://www.purplesucker.com http://www.myspace.com/supertrouperabba BLOGS: http://tronprog.blogspot.com http://longlivemusic.blogspot.com http://www.gnu.org/software/src-highlite http://www.gnu.org/software/gengetopt http://www.gnu.org/software/gengen http://doublecpp.sourceforge.net |
From: Lorenzo B. <be...@ds...> - 2009-03-09 15:59:15
|
Tor Lillqvist wrote: >> OK, then we're back to hardcode the path where the library (since from >> what I read above, there's no easy and reliable way to detect the right >> path) will be installed, > > Huh? You claim code as below is hard or unreliable (assuming we are > talking about a shared library)? > > static HMODULE dll = NULL; > > int __stdcall > DllMain (HINSTANCE hinstDLL, DWORD dwReason, LPVOID reserved) > { > if (dwReason == DLL_PROCESS_ATTACH) > dll = hinstDLL; > return TRUE; > } > > static char * > get_dll_directory (void) > { > char buf[1000]; > char *p; > > GetModuleFileNameA (dll, buf, sizeof (buf)); > p = _mbsrchr (buf, '\\'); > *p = '\0'; > return strdup (buf); > } > > (From memory more or less, so there might be slight errors, and all > error checking is missing.) > > Yes, using _mbsrchr() instead if strrchr() *is* essential if you want > your code to work in East Asia. And actually, what one ideally should > use for file names on Windows is wide character APIs and wchar_t > strings (GetModuleFileNameW(), wcsrchr().) mh... actually I come from the Unix world, and never dealt with dlls, so I was talking about dynamic libraries in Linux, which, when ported on windows, become static libraries, I guess... where this technique cannot be applied, can it? > >> and back to my problem that the path /usr/local will not work for fopen... > > Well, if you haven't learned anything from this thread, you indeed are > still where you started... > > One thing that I have failed to understand in this thread is whether > you really want that the choice for prefix (for instance the > /usr/local you keep coming back to) done at configure-time (when you > or whoever builds the software in question) determines a fixed > location where the software must be installed on end-user machines? > That is totally unacceptable on Windows in general. > well, yes, at least I'm talking about the default path which is hardcoded in the library (not a dll) and in the binary > For much software that is built also for Windows starting with a GNU > style configure script, the --prefix passed in is not actually used at > run-time. Instead, the software is freely installable in any location, > and one can even move the installation folder (as a whole tree, not > rearranging its subtrees) arbitrarily. This is true for instance for > the mingw gcc which was mentioned. and it uses dlls I guess? > > (Of course, if the software you are talking about is not going to be > distributed to arbitrary end-users, but only used inside one > organisation under the control of the builder/distributor, the > situation is different, and it is acceptable to require that it is > installed in a fixed location.) well, no it is also for ordinary users; but I think I'll try the autoconf macro that Keith was talking about and see whether it solves the problem. -- Lorenzo Bettini, PhD in Computer Science, DI, Univ. Torino ICQ# lbetto, 16080134 (GNU/Linux User # 158233) HOME: http://www.lorenzobettini.it MUSIC: http://www.purplesucker.com http://www.myspace.com/supertrouperabba BLOGS: http://tronprog.blogspot.com http://longlivemusic.blogspot.com http://www.gnu.org/software/src-highlite http://www.gnu.org/software/gengetopt http://www.gnu.org/software/gengen http://doublecpp.sourceforge.net |
From: Tor L. <tm...@ik...> - 2009-03-03 14:22:26
|
> how to find the location of the > executing binary from with the program itself? And also for libraries? GetModuleFileName() is your friend. --tml |
From: Earnie B. <ea...@us...> - 2009-03-03 16:18:21
|
Quoting Lorenzo Bettini <be...@ds...>: >> >> The onus belongs to the executor of configure to follow the directions. >> You can't guard against the idiots that don't follow the directions. > > mh... I don't think that's the case since we're talking about the > default configuration... > Why is your package different from all the other packages that offer a autoconf generated configure script? Earnie |
From: Lorenzo B. <be...@ds...> - 2009-03-05 08:25:12
|
Earnie Boyd wrote: > Quoting Lorenzo Bettini <be...@ds...>: > >>> The onus belongs to the executor of configure to follow the directions. >>> You can't guard against the idiots that don't follow the directions. >> mh... I don't think that's the case since we're talking about the >> default configuration... >> > > Why is your package different from all the other packages that offer a > autoconf generated configure script? it's not different... it's like all the others: it defaults $prefix to /usr.local and I hardcode the value of $prefix in my library and executable... by the way, this is the package I'm talking about http://www.gnu.org/software/src-highlite -- Lorenzo Bettini, PhD in Computer Science, DI, Univ. Torino ICQ# lbetto, 16080134 (GNU/Linux User # 158233) HOME: http://www.lorenzobettini.it MUSIC: http://www.purplesucker.com http://www.myspace.com/supertrouperabba BLOGS: http://tronprog.blogspot.com http://longlivemusic.blogspot.com http://www.gnu.org/software/src-highlite http://www.gnu.org/software/gengetopt http://www.gnu.org/software/gengen http://doublecpp.sourceforge.net |
From: Earnie B. <ea...@us...> - 2009-03-05 12:16:20
|
Quoting Lorenzo Bettini <be...@ds...>: > Earnie Boyd wrote: >> Quoting Lorenzo Bettini <be...@ds...>: >> >>>> The onus belongs to the executor of configure to follow the directions. >>>> You can't guard against the idiots that don't follow the directions. >>> mh... I don't think that's the case since we're talking about the >>> default configuration... >>> >> >> Why is your package different from all the other packages that offer a >> autoconf generated configure script? > > it's not different... it's like all the others: it defaults $prefix to > /usr.local and I hardcode the value of $prefix in my library and > executable... Then you should have zero concern for what the OS is or what the user does with --prefix. The onus belongs to the executor of configure to follow the directions for the OS in assigning the --prefix value. Earnie |
From: Lorenzo B. <be...@ds...> - 2009-03-06 09:09:54
|
Earnie Boyd wrote: > Quoting Lorenzo Bettini <be...@ds...>: > >> Earnie Boyd wrote: >>> Quoting Lorenzo Bettini <be...@ds...>: >>> >>>>> The onus belongs to the executor of configure to follow the directions. >>>>> You can't guard against the idiots that don't follow the directions. >>>> mh... I don't think that's the case since we're talking about the >>>> default configuration... >>>> >>> Why is your package different from all the other packages that offer a >>> autoconf generated configure script? >> it's not different... it's like all the others: it defaults $prefix to >> /usr.local and I hardcode the value of $prefix in my library and >> executable... > > Then you should have zero concern for what the OS is or what the user > does with --prefix. The onus belongs to the executor of configure to > follow the directions for the OS in assigning the --prefix value. mh... OK, I still don't agree... my point was only that if on the shell less /usr/local/share/myfile works, it should also work when issuing from within a program fopen("/usr/local/share/myfile") that's all -- Lorenzo Bettini, PhD in Computer Science, DI, Univ. Torino ICQ# lbetto, 16080134 (GNU/Linux User # 158233) HOME: http://www.lorenzobettini.it MUSIC: http://www.purplesucker.com http://www.myspace.com/supertrouperabba BLOGS: http://tronprog.blogspot.com http://longlivemusic.blogspot.com http://www.gnu.org/software/src-highlite http://www.gnu.org/software/gengetopt http://www.gnu.org/software/gengen http://doublecpp.sourceforge.net |
From: Earnie B. <ea...@us...> - 2009-03-06 12:17:22
|
Quoting Lorenzo Bettini <be...@ds...>: > > mh... OK, I still don't agree... my point was only that if on the shell > You seem to not understand that there are two very different C runtimes involved with your examples below. > less /usr/local/share/myfile > This one uses the MSYS runtime while > works, it should also work when issuing from within a program > > fopen("/usr/local/share/myfile") > this one is using the MSVCRT runtime. > that's all > And if you want to use a Cygwin runtime then use Cygwin (MSYS is a fork of Cygwin). MSVCRT has no idea what /usr/local/share/myfile is unless the current active drive happens to have such a directory. MSYS has a simplistic goal of being an interface between the UNIX scripting world and the natural windows program. The MinGW gcc builds natural windows programs. By natural I mean it uses the MSVCRT runtime. Earnie |