From: Ladislav M. <la...@li...> - 2010-09-08 13:08:13
|
Hello, I decided to give a try building MSYS itself inside fresh install done with mingw-get-inst and mingw-get and get fresh copy of sources from CVS. However building MSYS gives me a lot of errors and it was not so different using gcc-3.4.5 (now I'm using 4.5.0). Therefore I wonder what is the official way of building msys and what are prerequisilities. I just created build directory and used: <path_to_msys_rt_src>/configure && make but that gives a lot of undeclared identifiers and other errors. make passes some strange paths like: -I/usr/include/c++/3.2.2 -I/usr/include/c++/3.2.2/i686-pc-msys and -I/c/Src/msys/rt/src/winsup/w32api/include which probably assumes w32api to be checked into msys/rt/src/winsup Any pointers appreciated, ladis |
From: Earnie <ea...@us...> - 2010-09-08 15:52:29
|
Ladislav Michl wrote: > > Any pointers appreciated, > You mean like http://www.mingw.org/wiki/HOWTO? -- Earnie -- http://www.for-my-kids.com |
From: Ladislav M. <la...@li...> - 2010-09-08 16:46:10
|
On Wed, Sep 08, 2010 at 11:52:12AM -0400, Earnie wrote: > Ladislav Michl wrote: > > > > I just created build directory and used: > > <path_to_msys_rt_src>/configure && make > > but that gives a lot of undeclared identifiers and other errors. > > make passes some strange paths like: > > -I/usr/include/c++/3.2.2 -I/usr/include/c++/3.2.2/i686-pc-msys > > and -I/c/Src/msys/rt/src/winsup/w32api/include which probably assumes > > w32api to be checked into msys/rt/src/winsup This part is nicely solved by importing Makefile.common from Cygwin CVS. Does maintainer care himself or do he want me to enter patch into tracker? --- Makefile.common 14 Jan 2010 04:12:51 -0000 1.3 +++ Makefile.common 8 Sep 2010 15:51:03 -0000 @@ -1,6 +1,6 @@ # Makefile.common - common definitions for the winsup directory # -# Copyright 2000, 2001 Red Hat, Inc. +# Copyright 2000, 2001, 2002, 2003, 2004, 2005 Red Hat, Inc. # # This file is part of Cygwin. # @@ -10,7 +10,7 @@ # This makefile requires GNU make. -CFLAGS_COMMON:=-Wall -Wwrite-strings # -finline-functions +CFLAGS_COMMON:=-Wall -Wstrict-aliasing -Wwrite-strings -fno-common -pipe -fbuiltin -fmessage-length=0# -finline-functions MALLOC_DEBUG:=#-DMALLOC_DEBUG -I/cygnus/src/uberbaum/winsup/cygwin/dlmalloc MALLOC_OBJ:=#/cygnus/src/uberbaum/winsup/cygwin/dlmalloc/malloc.o @@ -29,10 +29,8 @@ pwd:=${shell pwd} ifneq "${filter winsup%,${notdir $(pwd)}}" "" -a:=${shell ${filter winsup%,${notdir $(pwd)}} >/dev/tty} here:=${pwd}/cygwin else -a:=${shell ${filter winsup%,${notdir $(pwd)}} >/dev/tty} here:=${dir $(pwd)}cygwin endif bupdir:=${shell cd $(here)/..; pwd} @@ -54,7 +52,6 @@ w32api_source:=$(updir)/w32api w32api_build:=$(bupdir)/w32api -w32api_include:=$(w32api_source)/include w32api_lib:=$(w32api_build)/lib newlib_source:=$(updir1)/newlib newlib_build:=$(bupdir1)/newlib @@ -64,13 +61,45 @@ mingw_source:=$(updir)/mingw utils_build:=$(bupdir)/utils utils_source:=$(updir)/utils +ifeq (,${findstring $(newlib_source)/libc/include,$(CFLAGS) $(CXXFLAGS) $(CXX) $(CC)}) +newlib_include:=-I$(newlib_source)/libc/include +endif +ifeq (,${findstring $(cygwin_source)/include,$(CFLAGS) $(CXXFLAGS) $(CXX) $(CC)}) +cygwin_include:=-I$(cygwin_source)/include +endif + +# Try to determine what directories are available in winsup. +# Attempt to properly detect missing mingw or w32api and adjust command +# line parameters appropriately -INCLUDES:=-I. -I$(cygwin_source)/include -I$(cygwin_source) -I$(newlib_source)/libc/sys/cygwin -I$(newlib_source)/libc/include -I$(w32api_include) $(W32API_CPPFLAGS) +# nostdinc:=${shell [ -d "$(updir)/w32api" ] && echo "-nostdinc"} +# ifneq (,$(nostdinc)) +nostdincxx:=-nostdinc++ +# ifeq (,${findstring $(w32api_source),$(CFLAGS) $(CXXFLAGS) $(CXX) $(CC)}) +w32api_include:=-I$(w32api_source)/include +# endif +# endif + +mingw_include:=${shell [ -d "$(mingw_source)/include" ] && echo "-I$(mingw_source)/include"} +ifneq (,$(mingw_include)) +nostdlib:=-nostdlib +else +nostdlib:= +endif + +ifeq (,${nostdlib}) +nostdinc:= +endif + +INCLUDES:=-I. $(cygwin_include) -I$(cygwin_source) $(newlib_include) $(w32api_include) ifdef CONFIG_DIR INCLUDES+=-I$(CONFIG_DIR) endif -MINGW_INCLUDES:=-I$(updir)/mingw/include $(INCLUDES) +MINGW_INCLUDES:=${mingw_include} $(w32api_include) +MINGW_CFLAGS:=-mno-cygwin $(MINGW_INCLUDES) +MINGW_CXXFLAGS:=${filter-out $(newlib_source)/%,$(CXXFLAGS)} -mno-cygwin $(MINGW_INCLUDES) +MINGW_LDFLAGS:=-B${mingw_build} -B${mingw_build}/mingwex GCC_DEFAULT_OPTIONS:=$(CFLAGS_COMMON) $(CFLAGS_CONFIG) $(INCLUDES) @@ -81,25 +110,25 @@ CRT0:=$(newlib_build)/libc/crt0.o ALL_CFLAGS:=$(DEFS) $(MALLOC_DEBUG) $(CFLAGS) $(GCC_DEFAULT_OPTIONS) -ALL_CXXFLAGS:=$(DEFS) $(MALLOC_DEBUG) $(CXXFLAGS) $(GCC_DEFAULT_OPTIONS) +ALL_CXXFLAGS=$(DEFS) $(MALLOC_DEBUG) $(CXXFLAGS) $(GCC_DEFAULT_OPTIONS) ifndef PREPROCESS c=-c o=.o else -c=-E +c=-E -dD o=.E endif libgcc:=${subst \,/,${shell $(CC_FOR_TARGET) -print-libgcc-file-name}} -GCC_INCLUDE:=${word 1,${dir $(libgcc)}}/include -CPP_INCLUDE:=/usr/include/c++/3.2.2 -CPP_TARGET_INCLUDE:=/usr/include/c++/3.2.2/i686-pc-msys - -COMPILE_CXX:=$(CXX) $c -nostdinc++ $(ALL_CXXFLAGS) -I$(GCC_INCLUDE) \ - -I$(CPP_INCLUDE) -I$(CPP_TARGET_INCLUDE) \ - -fno-rtti -fno-exceptions -COMPILE_CC:=$(CC) $c -nostdinc $(ALL_CFLAGS) -I$(GCC_INCLUDE) +gcc_libdir:=${word 1,${dir $(libgcc)}} +ifeq (,${findstring $(gcc_libdir),$(CFLAGS) $(CXXFLAGS) $(CXX) $(CC)}) +GCC_INCLUDE:=${subst //,/,-I$(gcc_libdir)/include} +endif + +COMPILE_CXX=$(CXX) $c $(if $($(*F)_STDINCFLAGS),,$(nostdincxx) $(nostdinc)) \ + $(ALL_CXXFLAGS) $(GCC_INCLUDE) -fno-rtti -fno-exceptions +COMPILE_CC=$(CC) $c $(if $($(*F)_STDINCFLAGS),,$(nostdinc)) $(ALL_CFLAGS) $(GCC_INCLUDE) vpath %.a $(cygwin_build):$(w32api_lib):$(newlib_build)/libc:$(newlib_build)/libm > > Any pointers appreciated, > > > > You mean like http://www.mingw.org/wiki/HOWTO? No. Especially this one http://www.mingw.org/wiki/HOWTO_Build_MSYS does not work for me out of the box. I'm assuming that people are building MSYS somehow and they are not keeping their local changes private. But I wouldn't be surprised they do. Compiling msys-1.0.dll for example gives me (with Makefile.common from Cygwin so those unreasonable paths went away): c++ -L/c/Src/msys/rt/bld/i686-pc-msys/winsup -L/c/Src/msys/rt/bld/i686-pc-msys/winsup/cygwin -isystem /c/Src/msys/rt/src/winsup/include -isystem /c/Src/msys/rt/src/winsup/cygwin/include -isystem /c/Src/msys/rt/src/newlib/libc/sys/cygwin -isystem /c/Src/msys/rt/src/newlib/libc/sys/cygwin32 -B/c/Src/msys/rt/bld/i686-pc-msys/newlib/ -isystem /c/Src/msys/rt/bld/i686-pc-msys/newlib/targ-include -isystem /c/Src/msys/rt/src/newlib/libc/include -c -nostdinc++ -DHAVE_CONFIG_H -g -O2 -Wall -Wstrict-aliasing -Wwrite-strings -fno-common -pipe -fbuiltin -fmessage-length=0 -I. -I/c/Src/msys/rt/src/winsup/cygwin -I/c/Src/msys/rt/src/winsup/w32api/include -I../../../../src/winsup/cygwin/config/i386 -Ic:/mingw/bin/../lib/gcc/mingw32/4.5.0/include -fno-rtti -fno-exceptions -o ./cygheap.o ../../../../src/winsup/cygwin/cygheap.cc In file included from ../../../../src/winsup/cygwin/thread.h:42:0, from ../../../../src/winsup/cygwin/dtable.h:14, from ../../../../src/winsup/cygwin/cygheap.cc:18: c:/Src/msys/rt/src/winsup/cygwin/include/pthread.h: 71:27: error: 'pthread_attr_t' was not declared in this scope ...etc ../../../../src/winsup/cygwin/thread.h: 505:17: error: 'sem_t' was not declared in this scope An obvious fix here is to include <cygwin/types.h> and <semaphore.h> into pthread.h, but I'm assuming it must be myself who has somehow screwed build environment. And I havent't found anything explaining how to do it correctly. Howtos provided are cookbooks - I hate those as they do not explain anything, just provides text to paste to my shell. For example pthread.h includes <sys/types.h> and pthread_attr_t is defined in msys\rt\src\winsup\cygwin\include\cygwin\types.h. Now question is where is <sys/include.h> supposed to point when building MSYS? As msys\rt\src\newlib\libc\include\sys\types.h contains the right definitions and even includes <cygwin\types.h> so there must be something wrong on my side. Thank you, ladis |
From: Ladislav M. <la...@li...> - 2010-09-08 17:07:32
|
On Wed, Sep 08, 2010 at 08:45:54PM +0200, Ladislav Michl wrote: > As msys\rt\src\newlib\libc\include\sys\types.h contains the right > definitions and even includes <cygwin\types.h> so there must be something > wrong on my side. Indeed, my fault. But it does not make HOWTO magically up-to-date, so I'll use newly gained experience to update it :-) |
From: Saeteurn S. <San...@gr...> - 2010-09-08 17:22:22
|
Howdy, I can't find this dll. I have searched on google and found this link that is suppose to link to it, but the link is broken. http://sourceforge.net/projects/mingw/files/MSYS%20gettext/gettext-0.17- 2/libintl-0.17-2-msys-dll-8.tar.lzma/download Where can I get it??? Thankies ^^ -San Saeteurn ________________________________ San Saeteurn Software Engineer, Switching and Routing Solutions Engineering Grass Valley, Inc. Tel: (1) 530 478 3571 Fax: (1) 530 478 4020 Cell: (1) 530 370 7294 E-mail: san...@gr... Mail: Grass Valley 400 Providence Mine Road Nevada City, CA, 95959 USA |
From: Saeteurn S. <San...@gr...> - 2010-09-08 17:49:36
|
Nevermind, I found it: http://sourceforge.net/projects/mingw/files/MSYS/BaseSystem/gettext/gettext-0.17-2/libintl-0.17-2-msys-dll-8.tar.lzma/download Thankies ^^ -San Saeteurn ________________________________ San Saeteurn Software Engineer, Switching and Routing Solutions Engineering Grass Valley, Inc. Tel: (1) 530 478 3571 Fax: (1) 530 478 4020 Cell: (1) 530 370 7294 E-mail: san...@gr... Mail: Grass Valley 400 Providence Mine Road Nevada City, CA, 95959 USA -----Original Message----- From: Saeteurn San [mailto:San...@gr...] Sent: Wednesday, September 08, 2010 10:21 AM To: MinGW Users List Subject: [Mingw-users] Can't find msys-intl-8.dll Howdy, I can't find this dll. I have searched on google and found this link that is suppose to link to it, but the link is broken. http://sourceforge.net/projects/mingw/files/MSYS%20gettext/gettext-0.17- 2/libintl-0.17-2-msys-dll-8.tar.lzma/download Where can I get it??? Thankies ^^ -San Saeteurn ________________________________ San Saeteurn Software Engineer, Switching and Routing Solutions Engineering Grass Valley, Inc. Tel: (1) 530 478 3571 Fax: (1) 530 478 4020 Cell: (1) 530 370 7294 E-mail: san...@gr... Mail: Grass Valley 400 Providence Mine Road Nevada City, CA, 95959 USA ------------------------------------------------------------------------------ This SF.net Dev2Dev email is sponsored by: Show off your parallel programming skills. Enter the Intel(R) Threading Challenge 2010. http://p.sf.net/sfu/intel-thread-sfd _______________________________________________ MinGW-users mailing list Min...@li... This list observes the Etiquette found at http://www.mingw.org/Mailing_Lists. We ask that you be polite and do the same. Disregard for the list etiquette may cause your account to be moderated. _______________________________________________ You may change your MinGW Account Options or unsubscribe at: https://lists.sourceforge.net/lists/listinfo/mingw-users |
From: Charles W. <cwi...@us...> - 2010-09-08 17:53:00
|
On 9/8/2010 1:21 PM, Saeteurn San wrote: > I can't find this dll. I have searched on google and found this link > that is suppose to link to it, but the link is broken. > http://sourceforge.net/projects/mingw/files/MSYS%20gettext/gettext-0.17- > 2/libintl-0.17-2-msys-dll-8.tar.lzma/download > > Where can I get it??? Stuff has been moved. Plus, the http://sourceforge.net/projects/mingw/files interface to sf files is... well... it just sux. The "beta" downloads/ interface is better... Look here: https://sourceforge.net/downloads/mingw/MSYS/BaseSystem/gettext/gettext-0.17-2/ -- Chuck |
From: Charles W. <cwi...@us...> - 2010-09-08 17:11:31
|
On 9/8/2010 2:45 PM, Ladislav Michl wrote: > On Wed, Sep 08, 2010 at 11:52:12AM -0400, Earnie wrote: >> Ladislav Michl wrote: >>> >>> I just created build directory and used: >>> <path_to_msys_rt_src>/configure && make >>> but that gives a lot of undeclared identifiers and other errors. >>> make passes some strange paths like: >>> -I/usr/include/c++/3.2.2 -I/usr/include/c++/3.2.2/i686-pc-msys Yes, those are strange. I'm not sure WHY winsup/Makefile.common hardcodes the c++ include paths for a very old cygwin compiler (and one that MSYS has never supported). However, since the directories don't exist the fact that they are there shouldn't hurt. However, I'm sure a patch to remove those two lines would be gratefully accepted. >>> and -I/c/Src/msys/rt/src/winsup/w32api/include which probably assumes >>> w32api to be checked into msys/rt/src/winsup In cygwin, the w32api and mingwrt sources ARE stored underneath src/winsup in the CVS repository itself. So, the makefiles FIRST look there. Now, in our snapshot, we don't include that subdirectory in *our* CVS repo -- so, there's nothing there, and the search continues (eventually "finding" the w32api headers under /usr/include, as installed by the w32api-x.xx-y-msys-dev package. > This part is nicely solved by importing Makefile.common from Cygwin CVS. > Does maintainer care himself or do he want me to enter patch into tracker? "Solved"? Not really...that version of Makefile.common has about six years of cygwin changes, not all of which are appropriate for MSYS. > -CFLAGS_COMMON:=-Wall -Wwrite-strings # -finline-functions > +CFLAGS_COMMON:=-Wall -Wstrict-aliasing -Wwrite-strings -fno-common -pipe -fbuiltin -fmessage-length=0# -finline-functions > MALLOC_DEBUG:=#-DMALLOC_DEBUG -I/cygnus/src/uberbaum/winsup/cygwin/dlmalloc > MALLOC_OBJ:=#/cygnus/src/uberbaum/winsup/cygwin/dlmalloc/malloc.o We don't want -Wstrict-aliasing; the MSYS snapshot of winsup was taken a long time before cygwin cleaned up many many aliasing issues. (That is, our source still has a lot of instances that will cause aliasing warnings). Do you really want to see them all? And that's just for starters. Look, the real issue is, you have not installed all of the packages that are necessary to build MSYS within MSYS. (Do you think the rest of us keep a bunch of "secret" patches around so the we can build MSYS, but preventing anyone else from doing so?) If you have such pervasive errors in your build (not reported by everyone else)...the likeliest explanation is not that the upstream repo is broken, but that your environment is. > In file included from ../../../../src/winsup/cygwin/thread.h:42:0, > from ../../../../src/winsup/cygwin/dtable.h:14, > from ../../../../src/winsup/cygwin/cygheap.cc:18: > c:/Src/msys/rt/src/winsup/cygwin/include/pthread.h: > 71:27: error: 'pthread_attr_t' was not declared in this scope > ...etc > ../../../../src/winsup/cygwin/thread.h: > 505:17: error: 'sem_t' was not declared in this scope > An obvious fix here is to include <cygwin/types.h> and <semaphore.h> > into pthread.h, but I'm assuming it must be myself who has somehow > screwed build environment. Yep. > And I havent't found anything explaining > how to do it correctly. First, you should install the following packages: msys-core-*-msys-*-dev msys-w32api-*-msys-*-dev msys-binutils-*-msys-*-bin msys-gcc-*-msys-*-bin] (and, if course, msys-base) I think you might ALSO need msys-gettext-*-msys-*-dev msys-libiconv-*-msys-*-dev But I'm not sure of that. If you just do this: mingw-get update mingw-get install msys-dvlpr That should ensure you have everything you need to build msys from CVS (except for the cvs client itself; it's assumed you MIGHT simply be trying to rebuild a pre-packaged -src version of msys-CORE). If you want cvs, just do mingw-get install msys-cvs-bin The real problem is (a) everything in the src/ repository is a little odd. It uses an old src structuring paradigm (called a "cygnus tree") where various subdirectories are configured/built IF and ONLY IF they exist -- but if they are missing, then that's not considered an error. This makes the build process very odd indeed. (b) the MSYS src takes advantage of this structure by omitting various directories (c) cygwin/msys are based on an underlying library, "newlib", which itself is quite complicated. It provides its own declarations and header files for many common unix/posix entities -- BUT allows clients to override with their own. Cygwin/MSYS do this for some headers, but not all. So it's often difficult to determine just WHICH "foo.h" is being used by the build! It really can't be explained very well, short of just WATCHING a successful build and inspecting the various (generated) makefiles. :-( -- Chuck |
From: Ladislav M. <la...@li...> - 2010-09-09 13:39:37
|
On Wed, Sep 08, 2010 at 01:11:24PM -0400, Charles Wilson wrote: > On 9/8/2010 2:45 PM, Ladislav Michl wrote: > >>> and -I/c/Src/msys/rt/src/winsup/w32api/include which probably assumes > >>> w32api to be checked into msys/rt/src/winsup > > In cygwin, the w32api and mingwrt sources ARE stored underneath > src/winsup in the CVS repository itself. So, the makefiles FIRST look > there. Now, in our snapshot, we don't include that subdirectory in > *our* CVS repo -- so, there's nothing there, and the search continues > (eventually "finding" the w32api headers under /usr/include, as > installed by the w32api-x.xx-y-msys-dev package. Installed fresh MinGW and MSYS including development packages. Note, that by default there is no /usr[*], but that is irrelevant for now. Bellow is gcc invocation as done by make during MSYS build. All sources are checked out in /c/Src: ls -l /c/Src drwxr-xr-x 8 Ladislav Michl Administrators 0 Aug 24 18:51 mingwrt drwxr-xr-x 6 Ladislav Michl Administrators 0 Sep 7 20:15 msys drwxr-xr-x 5 Ladislav Michl Administrators 0 Aug 31 09:15 w32api Build is done in /c/Src/msys/rt/bld using ../src/configure && make gcc -L/c/Src/msys/rt/bld/i686-pc-msys/winsup -L/c/Src/msys/rt/bld/i686-pc-msys/winsup/cygwin -isystem /c/Src/msys/rt/src/winsup/include -isystem /c/Src/msys/rt/src/winsup/cygwin/include -isystem /c/Src/msys/rt/src/newlib/libc/sys/cygwin -isystem /c/Src/msys/rt/src/newlib/libc/sys/cygwin32 -B/c/Src/msys/rt/bld/i686-pc-msys/newlib/ -isystem /c/Src/msys/rt/bld/i686-pc-msys/newlib/targ-include -isystem /c/Src/msys/rt/src/newlib/libc/include -c -nostdinc -DHAVE_CONFIG_H -g -O2 -Wall -Wwrite-strings -I. -I/c/Src/msys/rt/src/winsup/cygwin/include -I/c/Src/msys/rt/src/winsup/cygwin -I/c/Src/msys/rt/src/newlib/libc/sys/cygwin -I/c/Src/msys/rt/src/newlib/libc/include -I/c/Src/msys/rt/src/winsup/w32api/include -I../../../../src/winsup/cygwin/config/i386 -I/bin/../lib/gcc/i686-pc-msys/3.4.4//include -o ./glob.o ../../../../src/winsup/cygwin/glob.c > Look, the real issue is, you have not installed all of the packages that > are necessary to build MSYS within MSYS. (Do you think the rest of us > keep a bunch of "secret" patches around so the we can build MSYS, but > preventing anyone else from doing so?) Now I'm going to take this conspiracy seriously... win32 headers are not going to be found under /usr/include as make passes -nostdinc. Therefore the above gcc invocation fails with: ../../../../src/winsup/cygwin/glob.c:85:21: windows.h: No such file or directory Windows headers are likely to be found in -I/c/Src/msys/rt/src/winsup/w32api/include and that means someone should copy w32api module into /c/Src/winsup. Lets do this and run make again. Now linking fails with: /bin/ld: cannot find -lshell32 And indeed, libshell32.a is placed inside /lib/w32api, but there is no -L option pointing there. > If you have such pervasive errors in your build (not reported by > everyone else)...the likeliest explanation is not that the upstream repo > is broken, but that your environment is. Well, I was able to compile MSYS with msys-gcc and also with mingw32-gcc. The latter one needed much more effort and all msys-1.0.dll dependent binaries segfault. As it showed such configuration is unsupported I won't fix it. > > And I havent't found anything explaining how to do it correctly. > > First, you should install the following packages: Care to update http://www.mingw.org/wiki/HOWTO_Create_an_MSYS_Build_Environment ? I just created account on mingw.org, but it does not seem I'm allowed to do that myself. In fact every single document is outdated. I'd like to fix it at least MSYS howtos. And that presumes knowing how msys developers themselves are building MSYS. So I should perhaps ask "How do you build msys-1.0.dll?" Thank you, ladis [*] I remember reading somewhere what should me mounted under /usr by default, but do not remember any conclusion not I know if it still applies. |
From: Cesar S. <ces...@gm...> - 2010-09-09 14:20:52
|
On 9/9/2010 12:39, Ladislav Michl wrote: > I'd like to fix it at least MSYS howtos. Thanks. > And that presumes knowing how msys > developers themselves are building MSYS. So I should perhaps ask > "How do you build msys-1.0.dll?" You can take a look at the build script inside the source package. Here is the short version: 1) Install some build dependencies: build_deps=" msys-bash-bin msys-core-ext msys-coreutils-bin msys-diffutils-bin msys-findutils-bin msys-gawk-bin msys-grep-bin msys-make-bin msys-sed-bin msys-tar-bin msys-xz-bin msys-gcc-bin mingw32-gcc-g++ " mingw-get install $build_deps 2) Enter an MSYS build environment: start /msys MSYS 3) Set a few build flags: OPTFL="-fno-unit-at-a-time" export CFLAGS="-O3 -g ${OPTFL}" export LDFLAGS='-L/usr/lib/w32api' export CXXFLAGS="-O3 -g ${OPTFL}" export CPPFLAGS='-I/usr/include/w32api' export W32API_LDFLAGS=-L/usr/lib/w32api export W32API_CPPFLAGS=-I/usr/include/w32api If building with debug info: export CFLAGS='-O0 -g -DDEBUGGING' export CXXFLAGS='-O0 -g -DDEBUGGING' 4) Build it in a previously empty dir: ${path-to-source}/configure && make Regards, Cesar |
From: Earnie <ea...@us...> - 2010-09-09 16:36:54
|
Ladislav Michl wrote: > > Care to update > http://www.mingw.org/wiki/HOWTO_Create_an_MSYS_Build_Environment ? > I just created account on mingw.org, but it does not seem I'm allowed > to do that myself. In fact every single document is outdated. I'd like > to fix it at least MSYS howtos. And that presumes knowing how msys > developers themselves are building MSYS. So I should perhaps ask > "How do you build msys-1.0.dll?" > You should be able to edit the wiki pages now. http://www.mingw.org/wiki/MinGWiki_Pages gives details. As for /usr it is mapped to / by default but is allowed to be changed in /etc/fstab as of some recent version. -- Earnie -- http://www.for-my-kids.com |
From: Ladislav M. <la...@li...> - 2010-09-08 20:10:02
|
On Wed, Sep 08, 2010 at 01:11:24PM -0400, Charles Wilson wrote: > On 9/8/2010 2:45 PM, Ladislav Michl wrote: > "Solved"? Not really...that version of Makefile.common has about six > years of cygwin changes, not all of which are appropriate for MSYS. Yes, I consider it a solution and posted diff between msys and cygwin version for reference. See bellow. > > -CFLAGS_COMMON:=-Wall -Wwrite-strings # -finline-functions > > +CFLAGS_COMMON:=-Wall -Wstrict-aliasing -Wwrite-strings -fno-common -pipe -fbuiltin -fmessage-length=0# -finline-functions > > MALLOC_DEBUG:=#-DMALLOC_DEBUG -I/cygnus/src/uberbaum/winsup/cygwin/dlmalloc > > MALLOC_OBJ:=#/cygnus/src/uberbaum/winsup/cygwin/dlmalloc/malloc.o > > We don't want -Wstrict-aliasing; the MSYS snapshot of winsup was taken a > long time before cygwin cleaned up many many aliasing issues. (That is, > our source still has a lot of instances that will cause aliasing > warnings). Do you really want to see them all? > > And that's just for starters. It's easy to drop this change and I'm not suggesting to move to Cygwin version blindly, but it contains some interesting ideas. As I'm deploying w32api, mingwrt and msys on the save directory level I can benefit from makefile finding more recent w32api than installed from package. Sure, it needs to be modified, because msys hides cygwin stuff a bit deeper, but it is not necessary to reinvent it from scratch. I can post updated version if you are interested or just simply fix curent makefile that way. > Look, the real issue is, you have not installed all of the packages that > are necessary to build MSYS within MSYS. (Do you think the rest of us > keep a bunch of "secret" patches around so the we can build MSYS, but > preventing anyone else from doing so?) No. It's just some packages are comented out and it takes some time to figure out why (msys-gcc catalogue is not in msys-package-list.xml) > First, you should install the following packages: (cook book deleted, but many thanks for it! it is nice skeleton for wiki) > The real problem is (a) everything in the src/ repository is a little > odd. It uses an old src structuring paradigm (called a "cygnus tree") > where various subdirectories are configured/built IF and ONLY IF they > exist -- but if they are missing, then that's not considered an error. > This makes the build process very odd indeed. (b) the MSYS src takes > advantage of this structure by omitting various directories (c) > cygwin/msys are based on an underlying library, "newlib", which itself > is quite complicated. It provides its own declarations and header files > for many common unix/posix entities -- BUT allows clients to override > with their own. Cygwin/MSYS do this for some headers, but not all. So > it's often difficult to determine just WHICH "foo.h" is being used by > the build! Yes, I figured it out after I sent original question. What I was expecting from MSYS howto is how are things supposed to work. And since you just did it, I'm more than happy. > It really can't be explained very well, short of just WATCHING a > successful build and inspecting the various (generated) makefiles. :-( Well, at least trying to explain it might lead to better understand requirements and to improve build system. Patches will be sent to tracker. ladis |
From: Charles W. <cwi...@us...> - 2010-09-08 20:36:47
|
On 9/8/2010 4:43 PM, Ladislav Michl wrote: > No. It's just some packages are comented out Not anymore. > and it takes some time to figure > out why (msys-gcc catalogue is not in msys-package-list.xml) As of Monday afternoon, it is in there. Try looking again, after doing 'mingw-get update'. -- Chuck |
From: Ladislav M. <la...@li...> - 2010-09-08 22:15:51
|
On Wed, Sep 08, 2010 at 04:36:36PM -0400, Charles Wilson wrote: > > and it takes some time to figure > > out why (msys-gcc catalogue is not in msys-package-list.xml) > > As of Monday afternoon, it is in there. Try looking again, after doing > 'mingw-get update'. When it was not there yesterday I though it needs some time to get sf mirror synced. And today it seemed obvious something is wrong. mingw-get-inst-20100831.exe wants to be run as Administrator, but I'm using my computer as Power User. Then mingw-get update does nothing and catalogues are not updated. Unfortunately enough it appears to succeed, but fails silently. After fixing permitions it works as expected. ladis |
From: Charles W. <cwi...@us...> - 2010-09-08 22:41:11
|
On 9/8/2010 8:15 PM, Ladislav Michl wrote: > On Wed, Sep 08, 2010 at 04:36:36PM -0400, Charles Wilson wrote: >>> and it takes some time to figure >>> out why (msys-gcc catalogue is not in msys-package-list.xml) >> >> As of Monday afternoon, it is in there. Try looking again, after doing >> 'mingw-get update'. > > When it was not there yesterday I though it needs some time to get sf mirror > synced. And today it seemed obvious something is wrong. > > mingw-get-inst-20100831.exe wants to be run as Administrator, but I'm using > my computer as Power User. I have a number of planned changes for the next mingw-get-inst; that's one of them. Look for an update next week. > Then mingw-get update does nothing and catalogues > are not updated. Unfortunately enough it appears to succeed, but fails > silently. After fixing permitions it works as expected. Good. -- Chuck |