From: Michael P. <puj...@la...> - 2005-11-14 16:06:26
|
Hi Thanks for help, I successfully installed pkg-config. I obviously did not search enough as install is ... quite obvious. No I have a problem with libtool triggered by pkg-config paths. paths returned by pkg-config are of the form DRIVE:\<MingW>\... and path stored in .la files managed by libtool are of the form /local/lib/mylib.la This make ltmain.sh barf with the message: libtool: link: warning: `C:/msys/1.0/local/lib/libogg.la' seems to be moved because it compares string "/local/lib/" (extracted from libdir= line in /local/lib/libogg;la) with string "C:/msys/1.0/local/lib" which is derived from pkg-config after this warning when link it does not include the --ldflags of the lib (libogg in this case) and link fails. Any suggestion ? |
From: Ralf W. <Ral...@gm...> - 2005-11-14 16:36:33
|
Hi Michael, * Michael Pujos wrote on Mon, Nov 14, 2005 at 05:05:14PM CET: > > No I have a problem with libtool triggered by pkg-config paths. > > paths returned by pkg-config are of the form DRIVE:\<MingW>\... and path > stored in .la files managed by libtool are of the form > /local/lib/mylib.la > > This make ltmain.sh barf with the message: > > libtool: link: warning: `C:/msys/1.0/local/lib/libogg.la' seems to be moved Erm, this should be a warning only. But thanks for mentioning, we should fix this in some way (probably in Libtool). > because it compares string "/local/lib/" (extracted from libdir= line in > /local/lib/libogg;la) with string "C:/msys/1.0/local/lib" which is > derived from pkg-config Yes. > after this warning when link it does not include the --ldflags of the > lib (libogg in this case) and link fails. Are you saying the 'libtool --mode=link' command which also outputs above warning fails, or the one when you remove some --ldflags from the link line? If the latter, that would be a bug somewhere; could you send me the output of libtool --debug --mode=link [rest of command line] please, preferably packed? Thanks. Cheers, Ralf |
From: Michael P. <puj...@la...> - 2005-11-14 17:13:09
|
Ralf Wildenhues a =E9crit : >Hi Michael, > >* Michael Pujos wrote on Mon, Nov 14, 2005 at 05:05:14PM CET: > =20 > >>No I have a problem with libtool triggered by pkg-config paths. >> >>paths returned by pkg-config are of the form DRIVE:\<MingW>\... and pat= h=20 >>stored in .la files managed by libtool are of the form=20 >>/local/lib/mylib.la >> >>This make ltmain.sh barf with the message: >> >>libtool: link: warning: `C:/msys/1.0/local/lib/libogg.la' seems to be m= oved >> =20 >> > >Erm, this should be a warning only. But thanks for mentioning, we >should fix this in some way (probably in Libtool). > > =20 > Or maybe a new switch for pkg-config to generate /path/to/lib instead of=20 <full windows path to lib> ? > =20 > >>after this warning when link it does not include the --ldflags of the=20 >>lib (libogg in this case) and link fails. >> =20 >> > >Are you saying the 'libtool --mode=3Dlink' command which also outputs >above warning fails, or the one when you remove some --ldflags from the >link line? If the latter, that would be a bug somewhere; could you send >me the output of > libtool --debug --mode=3Dlink [rest of command line] > >please, preferably packed? Thanks. > > =20 > I think it is the second case (I mailed you the full debug). Here's the=20 error: make[3]: Leaving directory `/home/bobbie/libvorbis-1.1.1/lib/books' make[3]: Entering directory `/home/bobbie/libvorbis-1.1.1/lib' /bin/sh ../libtool --tag=3DCC --mode=3Dlink gcc -O20 -D__NO_MATH_INLINES= =20 -fsigned-char -DUSE_MEMORY_H -o libvorbisfile.la -rpath=20 /usr/local/lib -no-undefined -version-info 4:0:1 vorbisfile.lo libvorbis.= la C:/msys/1.0/local/lib/libogg.la libtool: link: warning: C:/msys/1.0/local/lib !=3D /usr/local/lib libtool: link: warning: `C:/msys/1.0/local/lib/libogg.la' seems to be mov= ed rm -fr .libs/libvorbisfile.dll.a gcc -shared .libs/vorbisfile.o -LC:/msys/1.0/local/lib=20 ./.libs/libvorbis.dll.a -o .libs/libvorbisfile-3.dll=20 -Wl,--image-base=3D0x10000000 -Wl,--out-implib,.libs/libvorbisfile.dll.a Creating library file: .libs/libvorbisfile.dll.a .libs/vorbisfile.o(.text+0x73):vorbisfile.c: undefined reference to=20 `ogg_sync_pageseek' .libs/vorbisfile.o(.text+0xb8):vorbisfile.c: undefined reference to=20 `ogg_sync_buffer' the line "libtool: link: warning: C:/msys/1.0/local/lib !=3D=20 /usr/local/lib" is me hacking ltmain.sh to see the problem this is the compilation of libvorbis-1.1.1 which depend on libogg.=20 libogg is installed, configure detected it with pkg-config. From the=20 line above libvorbis link without problem but libvorbisfile link failed because of a missing dependency (it=20 depends on libvorbis which is present on the link line and libvorbis=20 depends on libogg and that is missing). Looking at the log confirm there is a problem in building the dep of libvorbis. |
From: Michael P. <puj...@la...> - 2005-11-14 17:29:10
|
I tried regenerating configure & friends using the provided autogen.sh and things get even more complicated : ./configure fails: checking whether stripping libraries is possible... yes checking dynamic linker characteristics... ./configure: -print-search-dirs: command not found ./configure: -print-search-dirs: command not found Win32 ld.exe checking for memory.h... (cached) yes checking for cos in -lm... yes checking for pthread_create in -lpthread... no checking for pkg-config... yes ./configure: line 17561: syntax error near unexpected token `PKG_CHECK_MODULES(OGG,' ./configure: line 17561: ` PKG_CHECK_MODULES(OGG, ogg >= 1.0, HAVE_OGG=yes, HAVE_OGG=no)' |
From: Ralf W. <Ral...@gm...> - 2005-11-14 18:37:25
|
* Michael Pujos wrote on Mon, Nov 14, 2005 at 06:12:28PM CET: > Ralf Wildenhues a =E9crit : > >* Michael Pujos wrote on Mon, Nov 14, 2005 at 05:05:14PM CET: > > > >>paths returned by pkg-config are of the form DRIVE:\<MingW>\... and p= ath=20 > >>stored in .la files managed by libtool are of the form=20 > >>/local/lib/mylib.la > >> > >>This make ltmain.sh barf with the message: > >Erm, this should be a warning only. But thanks for mentioning, we > >should fix this in some way (probably in Libtool). > > > Or maybe a new switch for pkg-config to generate /path/to/lib instead o= f=20 > <full windows path to lib> ? Hmm. On second thought: if pkg-config generated the string C:/msys/1.0/local/lib/libogg.la then that should have been /usr/usr/local/lib/libogg.la instead, iff pkg-config has a way to produce this instead. At least for libtool libraries the latter path would always be correct, I believe. > I think it is the second case (I mailed you the full debug). Here's the= =20 > error: >=20 > make[3]: Leaving directory `/home/bobbie/libvorbis-1.1.1/lib/books' > make[3]: Entering directory `/home/bobbie/libvorbis-1.1.1/lib' > /bin/sh ../libtool --tag=3DCC --mode=3Dlink gcc -O20 -D__NO_MATH_INLIN= ES=20 > -fsigned-char -DUSE_MEMORY_H -o libvorbisfile.la -rpath=20 > /usr/local/lib -no-undefined -version-info 4:0:1 vorbisfile.lo libvorbi= s.la > C:/msys/1.0/local/lib/libogg.la > libtool: link: warning: C:/msys/1.0/local/lib !=3D /usr/local/lib > libtool: link: warning: `C:/msys/1.0/local/lib/libogg.la' seems to be m= oved > rm -fr .libs/libvorbisfile.dll.a > gcc -shared .libs/vorbisfile.o -LC:/msys/1.0/local/lib=20 > ./.libs/libvorbis.dll.a -o .libs/libvorbisfile-3.dll=20 > -Wl,--image-base=3D0x10000000 -Wl,--out-implib,.libs/libvorbisfile.dll.= a > Creating library file: .libs/libvorbisfile.dll.a > .libs/vorbisfile.o(.text+0x73):vorbisfile.c: undefined reference to=20 > `ogg_sync_pageseek' > .libs/vorbisfile.o(.text+0xb8):vorbisfile.c: undefined reference to=20 > `ogg_sync_buffer' Can you execute /bin/sh ../libtool --tag=3DCC --mode=3Dlink gcc -O20 -D__NO_MATH_INLIN= ES \ -fsigned-char -DUSE_MEMORY_H -o libvorbisfile.la -rpath \ /usr/local/lib -no-undefined -version-info 4:0:1 vorbisfile.lo \ libvorbis.la /usr/local/lib/libogg.la manually in the `/home/bobbie/libvorbis-1.1.1/lib' directory? Does it succeed? Does the build finish successfully then with another 'make', possibly after replacing some more paths manually? > the line "libtool: link: warning: C:/msys/1.0/local/lib !=3D=20 > /usr/local/lib" is me hacking ltmain.sh to see the problem OK. Cheers, Ralf |
From: Michael P. <puj...@la...> - 2005-11-14 18:52:12
|
>>Or maybe a new switch for pkg-config to generate /path/to/lib instead of >><full windows path to lib> ? >> >> > >Hmm. On second thought: if pkg-config generated the string > C:/msys/1.0/local/lib/libogg.la >then that should have been > /usr/usr/local/lib/libogg.la >instead, iff pkg-config has a way to produce this instead. At least for >libtool libraries the latter path would always be correct, I believe. > > > Yes >Can you execute > /bin/sh ../libtool --tag=CC --mode=link gcc -O20 -D__NO_MATH_INLINES \ > -fsigned-char -DUSE_MEMORY_H -o libvorbisfile.la -rpath \ > /usr/local/lib -no-undefined -version-info 4:0:1 vorbisfile.lo \ > libvorbis.la /usr/local/lib/libogg.la > >manually in the `/home/bobbie/libvorbis-1.1.1/lib' directory? Does it >succeed? Does the build finish successfully then with another 'make', >possibly after replacing some more paths manually? > > > It works and resuming make finishes without errors |
From: Keith M. <kei...@to...> - 2005-11-15 09:44:22
|
Ralf Wildenhues wrote: > Hmm. On second thought: if pkg-config generated the string > C:/msys/1.0/local/lib/libogg.la > then that should have been > /usr/usr/local/lib/libogg.la > instead, iff pkg-config has a way to produce this instead. > At least for libtool libraries the latter path would always be > correct, I believe. I've never used either libtool or pkg-config, but this problem appears to result from a comparison of path names generated by two separate tools, one of which uses Windoze native path format, while the second uses MSYS virtual path name format. For any tool which is going to compare path names reliably in the MSYS environment, I would suggest that all such paths be reduced to the native Windoze format. A few weeks ago, I posted this autoconf MSYS_AC_CANONICAL_PATH macro: http://article.gmane.org/gmane.comp.gnu.mingw.msys/2785 which does just that for any path name, when the expanded form is invoked in MSYS, while remaining safe, (actually resolving any path name to its canonical absolute form), on *nix systems. Perhaps libtool and/or pkg-config could adapt that for their needs. HTH. Regards, Keith. |
From: Dan O. <dan...@st...> - 2005-11-15 12:11:30
|
Hello, I'm having problems with code ported from Linux for negative strings converted to long longs and wonder if anyone can shed some light on this test case ... #include <iostream> #include <stdio.h> using namespace std; long long getInt(const char* mValue) { long long result = 0; char num[22]; strcpy(num,mValue); num[strcspn(num, " ")] = '\0'; sscanf(num,"%lld",&result); return result; } int main() { long long a =0; a=getInt("122"); cout << a <<endl; a =getInt("-122"); cout << a <<endl; } "122" gets converted to 122 but "-122" to 4294967174 Thanks in anticipation, Dan -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.362 / Virus Database: 267.13.0/168 - Release Date: 14/11/2005 |
From: mikael-aronsson <mik...@te...> - 2005-11-15 12:20:58
|
Hi ! Does %lld work ? isn't the sscanf in the msvrt dll ? and in that case it should use Microsoft format like %I64d, or am I wrongh here ? Mikael ----- Original Message ----- From: "Dan Osborne" <dan...@st...> To: <min...@li...> Sent: Tuesday, November 15, 2005 1:10 PM Subject: [Mingw-users] sscanf to long longs going awry for negative numbers > Hello, > > I'm having problems with code ported from Linux for negative strings > converted to long longs and wonder if anyone can shed some light on this > test case ... > > #include <iostream> > #include <stdio.h> > using namespace std; > long long getInt(const char* mValue) > { > long long result = 0; > char num[22]; > strcpy(num,mValue); > num[strcspn(num, " ")] = '\0'; > sscanf(num,"%lld",&result); > return result; > } > int main() > { > long long a =0; > a=getInt("122"); > cout << a <<endl; > a =getInt("-122"); > cout << a <<endl; > } > > "122" gets converted to 122 but "-122" to 4294967174 > > Thanks in anticipation, > > Dan > -- > No virus found in this outgoing message. > Checked by AVG Free Edition. > Version: 7.1.362 / Virus Database: 267.13.0/168 - Release Date: 14/11/2005 > > > > ------------------------------------------------------- > This SF.Net email is sponsored by the JBoss Inc. Get Certified Today > Register for a JBoss Training Course. Free Certification Exam > for All Training Attendees Through End of 2005. For more info visit: > http://ads.osdn.com/?ad_id=7628&alloc_id=16845&op=click > _______________________________________________ > MinGW-users mailing list > Min...@li... > > You may change your MinGW Account Options or unsubscribe at: > https://lists.sourceforge.net/lists/listinfo/mingw-users |
From: Dan O. <dan...@st...> - 2005-11-15 12:28:25
|
Mikael, Not for strings with a leading "-". However, the msdn docs imply ll is valid ... http://msdn2.microsoft.com/en-us/library/xdb9w69d.aspx Dan > -----Original Message----- > From: min...@li... > [mailto:min...@li...]On Behalf Of > mikael-aronsson > Sent: 15 November 2005 12:20 > To: min...@li... > Subject: Re: [Mingw-users] sscanf to long longs going awry for > negative numbers > > > Hi ! > > Does %lld work ? isn't the sscanf in the msvrt dll ? and in that case it > should use Microsoft format like %I64d, or am I wrongh here ? > > Mikael > > ----- Original Message ----- > From: "Dan Osborne" <dan...@st...> > To: <min...@li...> > Sent: Tuesday, November 15, 2005 1:10 PM > Subject: [Mingw-users] sscanf to long longs going awry for > negative numbers > > > > Hello, > > > > I'm having problems with code ported from Linux for negative strings > > converted to long longs and wonder if anyone can shed some light on this > > test case ... > > > > #include <iostream> > > #include <stdio.h> > > using namespace std; > > long long getInt(const char* mValue) > > { > > long long result = 0; > > char num[22]; > > strcpy(num,mValue); > > num[strcspn(num, " ")] = '\0'; > > sscanf(num,"%lld",&result); > > return result; > > } > > int main() > > { > > long long a =0; > > a=getInt("122"); > > cout << a <<endl; > > a =getInt("-122"); > > cout << a <<endl; > > } > > > > "122" gets converted to 122 but "-122" to 4294967174 > > > > Thanks in anticipation, > > > > Dan > > -- > > No virus found in this outgoing message. > > Checked by AVG Free Edition. > > Version: 7.1.362 / Virus Database: 267.13.0/168 - Release Date: > 14/11/2005 > > > > > > > > ------------------------------------------------------- > > This SF.Net email is sponsored by the JBoss Inc. Get Certified Today > > Register for a JBoss Training Course. Free Certification Exam > > for All Training Attendees Through End of 2005. For more info visit: > > http://ads.osdn.com/?ad_id=7628&alloc_id=16845&op=click > > _______________________________________________ > > MinGW-users mailing list > > Min...@li... > > > > You may change your MinGW Account Options or unsubscribe at: > > https://lists.sourceforge.net/lists/listinfo/mingw-users > > > > ------------------------------------------------------- > This SF.Net email is sponsored by the JBoss Inc. Get Certified Today > Register for a JBoss Training Course. Free Certification Exam > for All Training Attendees Through End of 2005. For more info visit: > http://ads.osdn.com/?ad_id=7628&alloc_id=16845&op=click > _______________________________________________ > MinGW-users mailing list > Min...@li... > > You may change your MinGW Account Options or unsubscribe at: > https://lists.sourceforge.net/lists/listinfo/mingw-users > -- > No virus found in this incoming message. > Checked by AVG Free Edition. > Version: 7.1.362 / Virus Database: 267.13.0/168 - Release Date: 14/11/2005 > -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.362 / Virus Database: 267.13.0/168 - Release Date: 14/11/2005 |
From: Tor L. <tm...@ik...> - 2005-11-15 12:48:52
|
Dan Osborne writes: > Not for strings with a leading "-". That's because sscanf() just treats the second "l" as a duplicate, and thinks the corrsponding variable is a 32-bit int. 122 fits into 32 bits, and storing a non-negative 32-bit int into 64-bit long long (that happens to be initialized to zero) happens to work on a little-endian platform. Try with larger non-negative numbers (like 1000000000000) and you will notice it doesn't work. > However, the msdn docs imply ll is valid > http://msdn2.microsoft.com/en-us/library/xdb9w69d.aspx That refers to the current version of the C library (MSVCR80.DLL). Mingw's compiler uses MSVCRT.DLL. The current Microsoft compilers also recognize "long long" while MSVC6 and MSVC7 use __int64. --tml |
From: Dan O. <dan...@st...> - 2005-11-15 14:40:51
|
That works - many thanks! I get some warnings that would be nice to circumvent ... dbinfo.cc:24: warning: int format, different type arg (arg 3) for sprintf(mValue,"%I64d",value); and more worryingly ... dbinfo.cc:157: warning: unknown conversion type character `I' in format dbinfo.cc:157: warning: too many arguments for format for ... #if __WIN32__ sprintf(mValue,"%I64d.%.*I64d",(val / pow), mScale, #else sprintf(mValue,"%lld.%.*lld",(val / pow), mScale, #endif (((val < 0) ? 0 - val : val) % pow)); Thanks, Dan > -----Original Message----- > From: min...@li... > [mailto:min...@li...]On Behalf Of Tor Lillqvist > Sent: 15 November 2005 12:49 > To: min...@li... > Subject: RE: [Mingw-users] sscanf to long longs going awry for > negative numbers > > > Dan Osborne writes: > > Not for strings with a leading "-". > > That's because sscanf() just treats the second "l" as a duplicate, and > thinks the corrsponding variable is a 32-bit int. 122 fits into 32 > bits, and storing a non-negative 32-bit int into 64-bit long long > (that happens to be initialized to zero) happens to work on a > little-endian platform. Try with larger non-negative numbers (like > 1000000000000) and you will notice it doesn't work. > > > However, the msdn docs imply ll is valid > > http://msdn2.microsoft.com/en-us/library/xdb9w69d.aspx > > That refers to the current version of the C library (MSVCR80.DLL). > Mingw's compiler uses MSVCRT.DLL. The current Microsoft compilers also > recognize "long long" while MSVC6 and MSVC7 use __int64. > > --tml > > > > ------------------------------------------------------- > This SF.Net email is sponsored by the JBoss Inc. Get Certified Today > Register for a JBoss Training Course. Free Certification Exam > for All Training Attendees Through End of 2005. For more info visit: > http://ads.osdn.com/?ad_id=7628&alloc_id=16845&op=click > _______________________________________________ > MinGW-users mailing list > Min...@li... > > You may change your MinGW Account Options or unsubscribe at: > https://lists.sourceforge.net/lists/listinfo/mingw-users > -- > No virus found in this incoming message. > Checked by AVG Free Edition. > Version: 7.1.362 / Virus Database: 267.13.0/168 - Release Date: 14/11/2005 > -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.362 / Virus Database: 267.13.0/168 - Release Date: 14/11/2005 |
From: Tor L. <tm...@ik...> - 2005-11-15 12:25:35
|
Dan Osborne writes: > sscanf(num,"%lld",&result); The Microsoft C library's sscanf() doesn't recognize the non-standard "ll". It uses the (equally non-standard) "I64". You should use: sscanf(num,"%I64d",&result); when using the Microsoft C library. --tml |
From: Ralf W. <Ral...@gm...> - 2005-11-15 12:25:46
|
Hi Keith, Michael, * Keith MARSHALL wrote on Tue, Nov 15, 2005 at 10:38:55AM CET: > Ralf Wildenhues wrote: > > Hmm. On second thought: if pkg-config generated the string > > C:/msys/1.0/local/lib/libogg.la > > then that should have been > > /usr/usr/local/lib/libogg.la > > instead, iff pkg-config has a way to produce this instead. > > At least for libtool libraries the latter path would always be > > correct, I believe. > > I've never used either libtool or pkg-config, but this problem > appears to result from a comparison of path names generated by > two separate tools, one of which uses Windoze native path format, > while the second uses MSYS virtual path name format. ACK. > For any tool which is going to compare path names reliably in the > MSYS environment, I would suggest that all such paths be reduced > to the native Windoze format. A few weeks ago, I posted this > autoconf MSYS_AC_CANONICAL_PATH macro: > http://article.gmane.org/gmane.comp.gnu.mingw.msys/2785 Thanks for the pointer! > which does just that for any path name, when the expanded form is > invoked in MSYS, while remaining safe, (actually resolving any path > name to its canonical absolute form), on *nix systems. Perhaps > libtool and/or pkg-config could adapt that for their needs. Yes probably. Using w32 paths throughout has its share of problems, too. For example, it makes path concatenation (for DESTDIR) hard. So for this alone, (since reverse mapping from the w32 path is hard), it would be better if pkg-config provided the unix-style path, iff possible. Note also, your macro requires that the path exists (which is fine for the issue at hand). In general, we cannot assume this in libtool (for all our uses of paths), so our strategy is to convert to w32 paths at the latest possible points. Michael, I have not received mail from you off-list yet, and assume my mail has not reached you either. You may want to try resending; I can only guess that, in case you zip'ed before, you may want to try a different packing method, or none FWIW. I need the trace in order to work on this issue. Cheers, Ralf |
From: Keith M. <kei...@to...> - 2005-11-15 13:00:31
|
Ralf Wildenhues wrote: [concerning Windoze vs. MSYS path name comparisons in libtool] > Yes probably. Using w32 paths throughout has its share of > problems, too. For example, it makes path concatenation (for > DESTDIR) hard. ... For that, you would probably need a complementary macro, which will map a native Windoze path to an MSYS virtual representation; (hint: cd WindozePath && pwd); but note that, even then, you would be likely to run into trouble with something like: C:/foo/bar --> /c/foo/bar because there isn't anything, except perhaps a UNC server reference, which you can logically place before the /c drive designation, unless you are willing to accept that you may create a directory called `c', at a lower level in the filesystem hierarchy. > ... So for this alone, (since reverse mapping from the w32 > path is hard), it would be better if pkg-config provided the > unix-style path, if possible. Note also, your macro requires > that the path exists ... No, it doesn't. It iteratively decomposes the given path name argument, until it finds an initial base path which *does* exist, converts that, and then reconstructs the original path name relative to that converted base. > ... (which is > fine for the issue at hand). In general, we > cannot assume this in libtool (for all our uses of paths), so our > strategy is to convert to w32 paths at the latest possible points. IME, it is nearly always best to handle path names in the canonical form native to the host OS. In MinGW/MSYS' case, this means in native Windoze format, (although I would stop short of using backslashes -- which are *not* generally required -- in place of slashes). This is particularly important, if the path name will ever end up encoded into program source, to be compiled by MinGW; here you *must* use native Windoze format, or the application will be unable to resolve the path name at runtime. Regards, Keith. |
From: Ralf W. <Ral...@gm...> - 2005-11-15 14:03:49
|
* Keith MARSHALL wrote on Tue, Nov 15, 2005 at 01:59:37PM CET: > Ralf Wildenhues wrote: > [concerning Windoze vs. MSYS path name comparisons in libtool] > > Yes probably. Using w32 paths throughout has its share of > > problems, too. For example, it makes path concatenation (for > > DESTDIR) hard. ... > > For that, you would probably need a complementary macro, which > will map a native Windoze path to an MSYS virtual representation; > (hint: cd WindozePath && pwd); Ah, ok. > but note that, even then, you > would be likely to run into trouble with something like: > > C:/foo/bar --> /c/foo/bar > > because there isn't anything, except perhaps a UNC server > reference, which you can logically place before the /c drive > designation, unless you are willing to accept that you may > create a directory called `c', at a lower level in the > filesystem hierarchy. I don't fully understand; this ./configure --prefix=/usr/local make make install DESTDIR=/tmp/dest mv /tmp/dest/usr/local/lib/* /usr/local/lib should and will work fine for most packages. Right? Even if I replace /usr/local with /c/foo/bar, I assume this will remain true. Right? Keep the comments coming -- thanks for everyone else's as well -- there are more wrong ideas in my brain that need to be fixed. My lack of experience with mingw/msys shows, unfortunately. > > ... So for this alone, (since reverse mapping from the w32 > > path is hard), it would be better if pkg-config provided the > > unix-style path, if possible. Note also, your macro requires > > that the path exists ... > > No, it doesn't. It iteratively decomposes the given path name > argument, until it finds an initial base path which *does* exist, > converts that, and then reconstructs the original path name > relative to that converted base. D'oh. Sorry for that braino of mine. Yes, the macro is much smarter than I originally saw. Nice! Also sorry for the braino of assuming that pkg-config /could/ provide the unix-style path. That is not possible (without an msys hack, which I did not intend at all). So, a fix in Libtool is needed. I'll try to write one. But I really simply need the trace output and/or something reproducible (plus some time) to do it, and add a test to Libtool so it does not break again. Note also that Libtool *is* prepared for w32 paths in most cases already (judging by a number of special cases and the lack of bug reports ;). Cheers, Ralf |
From: Keith M. <kei...@to...> - 2005-11-15 14:50:11
|
Ralf Wildenhues wrote, quoting me: >> but note that, even then, you >> would be likely to run into trouble with something like: >> >> C:/foo/bar --> /c/foo/bar >> >> because there isn't anything, except perhaps a UNC server >> reference, which you can logically place before the /c drive >> designation, unless you are willing to accept that you may >> create a directory called `c', at a lower level in the >> filesystem hierarchy. > > I don't fully understand; this > > ./configure --prefix=/usr/local > make > make install DESTDIR=/tmp/dest > mv /tmp/dest/usr/local/lib/* /usr/local/lib > > should and will work fine for most packages. Right? Even if I > replace /usr/local with /c/foo/bar, I assume this will remain true. > Right? Yes, in this scenario, that should still be ok. I simply wanted to raise your awareness of the convention used in MSYS, that an initial `/c/', `/d/', etc. represents the root of the Windoze block device, `C:/', `D:/' respectively, and that the file system isn't quite as homogeneous as the unix-style path name format may make it appear; some operations, at that `/c', `/d' level, may not work as you expect, or as they would with similarly named mount points on a real *nix platform. BTW, I've never understood the need to pollute the `make' namespace with the likes of `DESTDIR', in addition to `prefix'. Your example above could equally well be implemented as: ./configure --prefix=/usr/local make make install prefix=/tmp/dest mv /tmp/dest/usr/local/lib/* /usr/local/lib and should work just the same. It's this sort of unnecessary verbiage that puts me off using automake. You should also consider that, when configuring packages in MSYS it's usually better to specify the `prefix' as a native Windoze path -- the incantation: ./configure --prefix=`cd /usr/local && pwd -W` has often been recommended on this list, and on MinGW-msys; some packages even *require* this format -- `groff' is one example, of which I am specifically aware. Regards, Keith. |
From: Ralf W. <Ral...@gm...> - 2005-11-15 20:08:34
|
* Keith MARSHALL wrote on Tue, Nov 15, 2005 at 03:46:20PM CET: > > I simply wanted to > raise your awareness of the convention used in MSYS, that an initial > `/c/', `/d/', etc. represents the root of the Windoze block device, > `C:/', `D:/' respectively, and that the file system isn't quite as > homogeneous as the unix-style path name format may make it appear; > some operations, at that `/c', `/d' level, may not work as you > expect, or as they would with similarly named mount points on a > real *nix platform. OK. Thanks. By the way, now that I think of it, we already have one w32 related bugfix in branch-1-5 that is not in 1.5.20 (and lots of other ones). We hope to release 1.5.22 really soon (within weeks). > BTW, I've never understood the need to pollute the `make' namespace > with the likes of `DESTDIR', in addition to `prefix'. Your example > above could equally well be implemented as: > > ./configure --prefix=/usr/local > make > make install prefix=/tmp/dest > mv /tmp/dest/usr/local/lib/* /usr/local/lib > > and should work just the same. It's this sort of unnecessary > verbiage that puts me off using automake. Au contraire. I believe *one variable for one* use is a good concept. $prefix is for where the files will located when the installed software is used; the value of $prefix may be stored in the files created at build time (however ugly that may be; for example, on some systems shared libraries simply require hard coded paths). DESTDIR instead is to change the location where it is installed, e.g. into a mount point which will later appear somewhere else. Another couple of pragmatic reason against using prefix for the latter is that you usually should be able to do ../configure --prefix=/usr/local && make install DESTDIR=/tmp/dest and that some make implementations won't override a set macro: make install prefix=/tmp/dest Instead, you'd have to prefix=/tmp/dest make -e install which comes with its share of issues itself, if your environment contains other surprises. This is not an issue with DESTDIR, as it is not defined in Automake-created Makefiles. Surely the set of variables over which Automake claims responsibility is not easily recognizable (i.e., without reading the manual). Also it may be of help to note that much of what Automake does is realize the requirements listed in the GNU Coding Standards, however debatable or not they may be. Cheers, Ralf |
From: Keith M. <kei...@to...> - 2005-11-16 10:55:23
|
Ralf Wildenhues wrote, quoting me: >> and should work just the same. It's this sort of unnecessary >> verbiage that puts me off using automake. > > Au contraire. I believe *one variable for one* use is a good > concept. $prefix is for where the files will located when the > installed software is used; the value of $prefix may be stored > in the files created at build time (however ugly that may be; > for example, on some systems shared libraries simply require > hard coded paths). DESTDIR instead is to change the location > where it is installed, e.g. into a mount point which will later > appear somewhere else. Well, I'm afraid that we will just have to agree to disagree on this point. Quoting the autoconf 2.59 info docs: | Most of these variables have values that rely on `prefix' or | `exec=5Fprefix'. It is deliberate that the directory output | variables keep them unexpanded: typically `@datadir@' will be | replaced by `${prefix}/share', not `/usr/local/share'. | | This behavior is mandated by the GNU coding standards, so | that when the user runs: | | `make' | she can still specify a different prefix from the one | specified to `configure', in which case, if needed, the | package shall hard code dependencies corresponding to the | make-specified prefix. | | `make install' | she can specify a different installation location, in which | case the package =5Fmust=5F still depend on the location which | was compiled in (i.e., never recompile when `make install' | is run). This is an extremely important feature, as many | people may decide to install all the files of a package | grouped together, and then install links from the final | locations to there. | | In order to support these features, it is essential that | `datadir' remains being defined as `${prefix}/share' to depend | upon the current value of `prefix'. As I interpret that, the standard way to specify a prefix is to use configure's `--prefix' option, but that may be altered when invoking `make' to *build* the package, and may be overridden again, to specify an alternative installation point, by running `make prefix=3D<alt=5Finstall=5Fprefix> install'; this is also the technique implicitly mandated by the GNU Coding Standards: | Running ?make install? with a different value of prefix from | the one used to build the program should /not/ recompile the | program.=20 > Another couple of pragmatic reason against using prefix for the > latter is that you usually should be able to do > ../configure --prefix=3D/usr/local && make install \ > DESTDIR=3D/tmp/dest > and that some make implementations won't override a set macro: > make install prefix=3D/tmp/dest > Instead, you'd have to > prefix=3D/tmp/dest make -e install Such `make' implementations are broken. The GNU Coding Standards don't explicitly mandate the use of GNU make, but neither do they demand that such broken behaviour should be accommodated; I've seen it stated elsewhere that, when constructing a GNU package, it is not unreasonable to expect GNU compatible `make' behaviour. > which comes with its share of issues itself, if your environment > contains other surprises. This is not an issue with DESTDIR, as > it is not defined in Automake-created Makefiles. Really! It was when I last looked at automake, along with dozens of other redundant constructs, particularly several layers of `make' targets serving only to obfuscate the build process into complete incomprehensibility, through redirection to multiple levels of redirected targets, each serving no apparently useful purpose. > Surely the set of variables over which Automake claims > responsibility is not easily recognizable (i.e., without reading > the manual). This is precisely the problem with automake; it is yet another tool to learn, and so far I remain unconvinced that it delivers sufficient benefit to justify the expenditure of time to learn it. > Also it may be of help to note that much of what Automake does is > realize the requirements listed in the GNU Coding Standards, however > debatable or not they may be. And I can write a simpler, more comprehensible Makefile, without all of the automake verbiage, which will also conform to the GNU Coding Standards. Best regards, Keith. |
From: Ralf W. <Ral...@gm...> - 2005-11-17 20:30:32
|
Hi Keith, * Keith MARSHALL wrote on Wed, Nov 16, 2005 at 11:51:53AM CET: > Ralf Wildenhues wrote, quoting me: > >> and should work just the same. It's this sort of unnecessary > >> verbiage that puts me off using automake. > > > > Au contraire. I believe *one variable for one* use is a good > > concept. > Well, I'm afraid that we will just have to agree to disagree on > this point. Well, nothing bad about that. Would be boring if everyone agreed to everything all the time. :) > Quoting the autoconf 2.59 info docs: > As I interpret that, the standard way to specify a prefix is to > use configure's `--prefix' option, but that may be altered when > invoking `make' to *build* the package, and may be overridden > again, to specify an alternative installation point, by running > `make prefix=<alt_install_prefix> install'; this is also the > technique implicitly mandated by the GNU Coding Standards: > | Running ?make install? with a different value of prefix from > | the one used to build the program should /not/ recompile the > | program. Yes, they are a bit controversial in this point. But imagine this: You're doing a cross compile. The host system will need hardcoded paths in libraries (to be correct at run time), starting with $prefix. The package needs other, previously installed libraries, available below $DESTDIR/$prefix/lib. Currently we don't handle this well. Wouldn't it be nice if you specified at 'make' time (or 'configure' time, FWIW) both $prefix and $DESTDIR, relinking at 'make install' time would be unnecessary in this case? After all, you may not want or even be able to execute an uninstalled program in the cross-compiling setup. > > some make implementations won't override a set macro: > > make install prefix=/tmp/dest > > Instead, you'd have to > > prefix=/tmp/dest make -e install > > Such `make' implementations are broken. The GNU Coding Standards > don't explicitly mandate the use of GNU make, but neither do they > demand that such broken behaviour should be accommodated; I've > seen it stated elsewhere that, when constructing a GNU package, it > is not unreasonable to expect GNU compatible `make' behaviour. Broken or not: they are still in use. I remember one or two related bug reports against Libtool in the last year. Look Keith, I'm not even defending the GCS -- I don't want to, I have my issues with them as well. All I am is trying to state a few facts and give a few reasons. Neither am I trying to advertise Automake. Your needs may be different from other people's needs. > > which comes with its share of issues itself, if your environment > > contains other surprises. This is not an issue with DESTDIR, as > > it is not defined in Automake-created Makefiles. > > Really! Look: it does not _set_ DESTDIR, i.e., it does not contain DESTDIR = I did not say it does not _use_ $(DESTDIR). > It was when I last looked at automake, along with dozens > of other redundant constructs, particularly several layers of `make' > targets serving only to obfuscate the build process into complete > incomprehensibility, through redirection to multiple levels of > redirected targets, each serving no apparently useful purpose. This is unspecific criticism. If you can state a specific item you think is not necessary or can be done in a better way, or you don't understand, then by all means, please go ahead and describe it, so it can be fixed. Otherwise, I'll just ignore this -- nontechnical discussion about this is a mere waste of time to me. Surely for GNU make the created Makefiles could be simpler; AFAIR the idea of optionally creating GNU make-specific Makefiles has been considered but abandoned/not yet pursued due to increased complexity and lack of time/motivation. OTOH, as a user I rarely need to look at the created Makefiles. > > Surely the set of variables over which Automake claims > > responsibility is not easily recognizable (i.e., without reading > > the manual). > > This is precisely the problem with automake; it is yet another tool > to learn, and so far I remain unconvinced that it delivers sufficient > benefit to justify the expenditure of time to learn it. Fair enough. Nobody is trying to persuade you. If you've been fine without it, by all means don't change. > > Also it may be of help to note that much of what Automake does is > > realize the requirements listed in the GNU Coding Standards, however > > debatable or not they may be. > > And I can write a simpler, more comprehensible Makefile, without all > of the automake verbiage, which will also conform to the GNU Coding > Standards. Fair enough as well. Do you use a similarly elaborate dependency tracking mechanism, by the way? Cheers, Ralf |
From: Earnie B. <ea...@pr...> - 2005-11-22 13:47:41
|
Quoting Ralf Wildenhues <Ral...@gm...>: > > But imagine this: You're doing a cross compile. The host system will > need hardcoded paths in libraries (to be correct at run time), starting > with $prefix. The package needs other, previously installed libraries, > available below $DESTDIR/$prefix/lib. > One shouldn't use DESTDIR that way. See below for followup. > Currently we don't handle this well. Wouldn't it be nice if you > specified at 'make' time (or 'configure' time, FWIW) both $prefix and > $DESTDIR, relinking at 'make install' time would be unnecessary in > this case? After all, you may not want or even be able to execute an > uninstalled program in the cross-compiling setup. > As I understand the purpose of DESTDIR it is only to be used as an aid in packaging prebuilt binaries. It is not to be used to install binaries I build for my machine. That is what prefix is for. Kind Regards, Earnie Boyd For all your online shopping needs http://shop.siebunlimited.com. Register an account online and receive a 10% discount on your first purchase. |
From: Keith M. <kei...@to...> - 2005-11-22 14:49:47
|
Earnie Boyd wrote: > As I understand the purpose of DESTDIR it is only to be used as > an aid in packaging prebuilt binaries. It is not to be used to > install binaries I build for my machine. That is what prefix > is for. And even for packaging prebuilt binaries, DESTDIR is fundamentally redundant -- the same effect can be achieved by redefining prefix for the `make install' command, as I do in the groff-mingwPORT ./configure --prefix=`cd /mingw && pwd -W` make builds the package for a default installation in the MinGW tree, with any compiled in paths correctly defined, then rm -rf packagedir mkdir packagedir make prefix=`pwd`/packagedir install cd packagedir tar chf - . | gzip -c >../package.tar.gz creates the binary package tarball. This may be subsequently installed by cd /mingw gzip -c -d /path/to/package.tar.gz | tar xf - The only issue not well handled is the preservation and updating of `dir' files for `info', which need a bit more work, but no definition of DESTDIR will help with this anyway. BTW, any Makefile which defines an installation command similar to $(INSTALL) binfile$(EXEEXT) $(DESTDIR)$(prefix)/binfile$(EXEEXT) is fundamentally broken, in the MSYS arena, since, if prefix is correctly defined as a Win32 path, e.g. `C:/mingw', (as it *should* be), there is no valid definition for DESTDIR, other than an empty string, which can legitimately preceed it. Regards, Keith. |
From: Ralf W. <Ral...@gm...> - 2005-11-25 08:42:06
|
Hi Earnie, * Earnie Boyd wrote on Tue, Nov 22, 2005 at 02:49:51PM CET: > Quoting Ralf Wildenhues <Ral...@gm...>: > > > >But imagine this: You're doing a cross compile. The host system will > >need hardcoded paths in libraries (to be correct at run time), starting > >with $prefix. The package needs other, previously installed libraries, > >available below $DESTDIR/$prefix/lib. > > One shouldn't use DESTDIR that way. See below for followup. It's not documented to be used that way. Correct. > As I understand the purpose of DESTDIR it is only to be used as an aid in > packaging prebuilt binaries. It is not to be used to install binaries I > build for my machine. That is what prefix is for. This is what DESTDIR is documented for. Yes. Or building for a chrooted system. Or building and installing without root priviledges. I am not saying prefix could not be used for this. Above would be an extension to its current use. I am trying to find out whether it is a safe one or not. Likely it's not. I ask 10 people how they do cross-compilation, and I get 10 subtly different, inconsistent answers. :-/ In any case, there is another (good?) reason for DESTDIR over changing prefix upon installation: DESTDIR allows the user to adjust _all_ paths at once, and be certain the paths do not end up in the installed files. E.g., I can configure --prefix=/usr/local --sysconfdir=/etc [...] make all install DESTDIR=/tmp/staging when I am not root, for example; without having to reset all other paths I might have specified explicitly. Surely that is a convenience (for the *user*, not the developer) rather than a technical necessity, and surely it does not work with w32 paths. Funnily, it was you who seemed to state a while ago[1] that MSYS could be used to circumvent this. :) For more information on why DESTDIR may be useful for some people, see e.g. this thread[2]. Cheers, Ralf [1] http://lists.gnu.org/archive/html/autoconf/2003-01/msg00031.html [2] http://gcc.gnu.org/ml/libstdc++/2003-01/msg00085.html |
From: Keith M. <kei...@to...> - 2005-11-25 11:15:20
|
Ralf Wildenhues wrote: > In any case, there is another (good?) reason for DESTDIR over > changing prefix upon installation: DESTDIR allows the user to > adjust _all_ paths at once, and be certain the paths do not end > up in the installed files. > E.g., I can > configure --prefix=/usr/local --sysconfdir=/etc [...] > make all install DESTDIR=/tmp/staging > > when I am not root, for example; without having to reset all > other paths I might have specified explicitly. Surely that is > a convenience (for the *user*, not the developer) rather than a > technical necessity, ... I will concede that DESTDIR may offer some convenience to a miniscule minority of users, who habitually force some of the autoconf standard path declarations to be independent of prefix, and then install to a location to be subsequently accessed via chroot, but ... > and surely it does not work with w32 paths. It is neither use nor ornament in the Win32 arena, or for that matter the MS-DOS arena; in both of these arenas, it is utterly broken. Here, if a Makefile includes any installation command specifying a destination relative to $(DESTDIR)$(prefix), or indeed any other Makefile variable such as $(bindir), which is dependent on $(prefix), it is imperative that DESTDIR is *never* assigned any value, other than the empty string. That said, and while I remain unconvinced that DESTDIR is anything more that an ugly kludge, of limited utility, it is harmless if it is used only in installation rules, *exactly* in the habitual form `$(DESTDIR)$(prefix)', and it is subsequently ignored altogether, so I really don't want to debate the issue further. > Funnily, it was you [Earnie] who seemed to state a while ago that > MSYS could be used to circumvent this. :) > http://lists.gnu.org/archive/html/autoconf/2003-01/msg00031.html I can't speak for Earnie, but my guess is that when he wrote that, he was thinking along the lines of "MSYS understands the convention that `/c/local/bin' represents the Win32 native `C:/local/bin', so, if I specify `--prefix=/c/local', then any installation rule using `DESTDIR=/d/tmp' would resolve to an MSYS path of `/d/local/c/local'; this in turn would resolve to the Win32 path `D:/local/c/local', which could represent a real Win32 path". More recent experience has taught us that we really need to specify prefix as a real Win32 path, e.g. `--prefix=C:/local', because the MSYS specific `/c/local' is invalid in the context of the native Win32 application which we are using MinGW to build, even though it *is* valid in the MSYS context in which we perform the build, and is therefore understood, and appropriately resolved by msys-make. > For more information on why DESTDIR may be useful for some people, > see e.g. this thread[2]. > http://gcc.gnu.org/ml/libstdc++/2003-01/msg00085.html Well, I've read that, and I see nothing which would even begin to convince me that DESTDIR has any practical value. Regards, Keith. |
From: Tor L. <tm...@ik...> - 2005-11-15 13:03:41
|
Ralf Wildenhues writes: > it would be better if pkg-config provided the unix-style path, iff > possible. Since pkg-config is a freestanding Win32 console application with no relation to or knowledge of MSYS (or Cygwin), I don't think that is possible. Unless it is incorporated into MSYS? --tml |