Thanks, that was indeed the tty output log from running "make" >& make.out, where a number of xxx.lo objects were already created and this command was supposed to start building a shared library. Following this:
make[1]: *** [magick/libGraphicsMagick.la] Error 1 make[1]: Leaving directory `/mingw/sources/GraphicsMagick-1.3.20/bldshared' make: *** [all] Error 2 I went to my Cygwin64 installation, its compiler (x86_w64-pc-cygwin (posix, 4.8.3, dwarf) had no problems with GraphicsMagick, and the link had no issues: ============== make.out using x86_w64-pc-cygwin: /bin/sh ./libtool --tag=CC --mode=link gcc -O2 -std=gnu99 -fopenmp -I/usr/local/include -Wall -no-undefined -export-symbols-regex ".*" -version-info 15:0:12 -L/opt/local/lib -L/usr/local/lib -L/usr/lib -L/usr/lib -o magick/libGraphicsMagick.la -rpath /opt/bld/GraphicsMagick-1.3.20/lib magick/magick_libGraphicsMagick_la-analyze.lo (etc) coders/magick_libGraphicsMagick_la-ept.lo coders/magick_libGraphicsMagick_la-tiff.lo coders/magick_libGraphicsMagick_la-x.lo coders/magick_libGraphicsMagick_la-xwd.lo filters/magick_libGraphicsMagick_la-analyze.lo -ljbig -llcms2 -ltiff -lfreetype -ljpeg -lpng15 -lwmflite -lXext -lSM -lICE -lX11 -llzma -lbz2 -lxml2 -lz -lgdi32 -lm -lgomp -lpthread (successful) ================ ======== using i686-win32-sjlj, 4.8.2) $ grep -n lpng1 ../bldE/make.out 705:/bin/sh ./libtool --tag=CC --mode=link gcc -O2 -mtune=pentium3 -std=gnu99 -fopenmp -I/local32/include -Wall -pthread -no-undefined -export-symbols-regex ".*" -version-info 15:0:12 -L/local32/lib -L/local32/lib -L/local32/lib -o magick/libGraphicsMagick.la -rpath /build32/GM1.3.20share/lib magick/magick_libGraphicsMagick_la-analyze.lo magick/magick_libGraphicsMagick_la-annotate.lo magick/magick_libGraphicsMagick_la-attribute.lo (etc) coders/magick_libGraphicsMagick_la-ept.lo coders/magick_libGraphicsMagick_la-tiff.lo coders/magick_libGraphicsMagick_la-webp.lo filters/magick_libGraphicsMagick_la-analyze.lo -lwebp -ltiff -lfreetype -ljpeg -lpng16 -lwmflite -lbz2 -lxml2 -lz -lgdi32 -lm -lgomp -lpthread ============= (above error. Looking for libpng16 in usr/local/lib when it was waiting in /local32/lib) Because the two compilers are fed the same line, I'm inclined to believe improving the shell environment with msys2 will not help. I have downloaded msys2 now, though, and anticipate using it for 64-bit builds once I'm more comfortable with it. On Sat, Nov 1, 2014 at 6:57 PM, Ray Donnelly <[email protected]> wrote: > I'm tired, corrections inline: > > On Sun, Nov 2, 2014 at 1:54 AM, Ray Donnelly <[email protected]> > wrote: > > On Sun, Nov 2, 2014 at 1:19 AM, Greg Jung <[email protected]> wrote: > >> Hi guys, > >> > >> I am using mingw-w64 gcc v4.8.2 installed under the /mingw32 directory > under > >> mingw and I compile using msys/1.0 shell, or CMAKE from msys using "MSYS > >> Makefiles". > >> I adopted this after installing from a recipe and found it worked more > often > >> than not in situations where plain mingw/msys (installed on same > computer) > >> failed. So I've been pretty happy with things but as my projects get > larger > >> I need a better understanding of the general configuration and what gcc > >> expects - especially the linker utilities. > >> > >> 2 quick questions: > >> Is MSYS2 really neccessary to work with mingw-m64 compilers? I've > managed > >> OK with msys-1.0. > > > > No, cmd.exe is enough to work with mingw-w64 compilers, or an IDE such > > as QtCreator, CodeLite or Eclipse could be used. If you want a bash > > command line, then MSYS2 is much better than MSYS. > > Speaking for the core of MSYS2, it is forked from (and re-syncs > > regularly with) current Cygwin which has ~15 years more bugfixes and > > features applied to it than MSYS, it has 64bit support (so that dll > > rebase issues practically vanish) and whereas make -jN (where N>1) > > fails often with MSYS1 it is reliable on MSYS2 (due to improvements to > > the core of Cygwin). > > > > With regard to the user-space programs, MSYS2 provides bleeding edge > > versions of build tools such as bash, gnumake, perl, python, git, svn, > > cmake, gyp etc. > > > >> > >> I tried to overlay the 4.9.1 gcc-tools distribution on a /mingw32 tree > >> under my older mingw installation, but the failure of a configure > (couldn't > >> determine default exec file) indicates I may need to do something more: > >> true? if so, what? > >> > >> --------------------- > >> My current problem is from trying to make a shared library in > >> graphicsMagick, > >> this line is the first link attempt after compilation: > >> bin/sh ./libtool --tag=CC --mode=link gcc -O2 -mtune=pentium3 \ > >> (more flags) \ > >> -L/local32/lib -o magick/libGraphicsMagick.la -rpath > >> /build32/GM1.3.20share/lib \ > >> (long list of .lo files) \ > >> magick/magick_libGraphicsMagick_la-analyze.lo \ > >> XXX..analyze.lo -lwebp -ltiff -lfreetype -ljpeg -lpng16 -lwmflite > -lbz2 > >> -lxml2 -lz -lgdi32 -lm -lgomp -lpthread > >> > >> /bin/grep: /usr/local/lib/libpng16.la: No such file or directory > >> /bin/sed: can't read /usr/local/lib/libpng16.la: No such file or > directory > >> libtool: link: `/usr/local/lib/libpng16.la' is not a valid libtool > archive > >> ------------------------------------------------------- > >> I'm guessing webp, freetype, jpeg and tiff were ready to load from the > >> compiler tree, and png16 was the first library to get > >> loaded from the library: -L/local32/lib=LDFLAGS holds all of these but > it > >> went to search in /usr/local/lib. ???. > > > > You'll have to find someone with a better opinion of MSYS than I to > > help you out with that, but you provide very much useful information > * but you didn't provide > > like the cmake command line or output log. > > > > On MSYS2 you can benefit from prebuilt binaries for many programs, > > tools and libraries, including most (if not all) of the ones you need. > > As well as prebuilt binaries, the packaging system (a fork of > > ArchLinux's Pacman) includes makepkg{,-mingw} which uses PKGBUILD > > files to allow repeatable from-source builds. Without apologies for > * With apologies > > attempting to speak for the other MSYS2 developers, we aim for MSYS2 > > to be to Windows what Homebrew is to OSX, roughly speaking. > > > > We've got a few wrinkles to iron out concerning package updates, but > > we are making progress on that. Even if you don't want to drink from > > our precompiled kool-aid, using (and contributing to) the PKGBUILD > > repositories will likely have good value for you. > > > > Feel free to drop by #msys2 on oftc IRC, or ask questions on our > > mailing list: https://sourceforge.net/p/msys2/mailman/msys2-users/ > > > > Best regards, > > > > Ray. > > > >> > >> > ------------------------------------------------------------------------------ > >> > >> _______________________________________________ > >> Mingw-w64-public mailing list > >> [email protected] > >> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public > >> > > > ------------------------------------------------------------------------------ > _______________________________________________ > Mingw-w64-public mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/mingw-w64-public >
------------------------------------------------------------------------------
_______________________________________________ Mingw-w64-public mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
