[Mingw-users] g++ --output-lib option

210 views
Skip to first unread message

Christoph Groth

unread,
Mar 15, 2012, 9:42:35 AM3/15/12
to mingw...@lists.sourceforge.net
Dear MinGW experts,

I'm trying to compile (under Windows 7) our project which is mainly
implemented in Python but includes several C and a C++ extensions. I've
installed the latest MinGW (which is based on GCC 4.6.1) from
http://mingw.org/.

When I try to build our project in the way which sould work I get an
error message about g++ not knowing the --output-lib option.
Unfortunately I could not find any information about this option. The
changelog of gcc dosen't seem to mention it. All I know is that dlltool
has an option of the same name.

Why and when was --output-lib removed and what to do to replace it?

Thanks,
Christoph


E:\Work\kwant-0.1.4>python setup.py build -c mingw32
running build
running build_py
running build_ext
building 'kwant.graph.slicer' extension
c:\mingw\bin\gcc.exe -mdll -O -Wall -IC:\Python27\lib\site-packages\numpy\core\i
nclude -IC:\Python27\include -IC:\Python27\PC -c kwant/graph/slicer.c -o build\t
emp.win32-2.7\Release\kwant\graph\slicer.o
kwant/graph/slicer.c: In function '__pyx_pf_5kwant_5graph_6slicer_slice':
kwant/graph/slicer.c:1145:14: warning: variable '__pyx_bshape_0_rightarr' set bu
t not used [-Wunused-but-set-variable]
kwant/graph/slicer.c:1144:14: warning: variable '__pyx_bstride_0_rightarr' set b
ut not used [-Wunused-but-set-variable]
kwant/graph/slicer.c:1142:14: warning: variable '__pyx_bshape_0_leftarr' set but
not used [-Wunused-but-set-variable]
kwant/graph/slicer.c:1141:14: warning: variable '__pyx_bstride_0_leftarr' set bu
t not used [-Wunused-but-set-variable]
kwant/graph/slicer.c: At top level:
C:\Python27\lib\site-packages\numpy\core\include/numpy/__multiarray_api.h:1532:1
: warning: '_import_array' defined but not used [-Wunused-function]
C:\Python27\lib\site-packages\numpy\core\include/numpy/__ufunc_api.h:226:1: warn
ing: '_import_umath' defined but not used [-Wunused-function]
c:\mingw\bin\gcc.exe -mdll -O -Wall -IC:\Python27\lib\site-packages\numpy\core\i
nclude -IC:\Python27\include -IC:\Python27\PC -c kwant/graph/c_slicer/partitione
r.cc -o build\temp.win32-2.7\Release\kwant\graph\c_slicer\partitioner.o
kwant/graph/c_slicer/partitioner.cc: In member function 'void Partitioner::bisec
tFirst(std::vector<int>&, std::vector<int>&, double, int, int)':
kwant/graph/c_slicer/partitioner.cc:114:51: warning: comparison between signed a
nd unsigned integer expressions [-Wsign-compare]
c:\mingw\bin\gcc.exe -mdll -O -Wall -IC:\Python27\lib\site-packages\numpy\core\i
nclude -IC:\Python27\include -IC:\Python27\PC -c kwant/graph/c_slicer/slicer.cc
-o build\temp.win32-2.7\Release\kwant\graph\c_slicer\slicer.o
writing build\temp.win32-2.7\Release\kwant\graph\slicer.def
c:\mingw\bin\g++.exe -mdll -static --output-lib build\temp.win32-2.7\Release\kwa
nt\graph\libslicer.a --def build\temp.win32-2.7\Release\kwant\graph\slicer.def -
s build\temp.win32-2.7\Release\kwant\graph\slicer.o build\temp.win32-2.7\Release
\kwant\graph\c_slicer\partitioner.o build\temp.win32-2.7\Release\kwant\graph\c_s
licer\slicer.o -LC:\Python27\libs -LC:\Python27\PCbuild -lpython27 -lmsvcr90 -o
build\lib.win32-2.7\kwant\graph\slicer.pyd
g++: error: build\temp.win32-2.7\Release\kwant\graph\libslicer.a: No such file o
r directory
g++: error: unrecognized option '--output-lib'
error: command 'g++' failed with exit status 1


------------------------------------------------------------------------------
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here
http://p.sf.net/sfu/sfd2d-msazure
_______________________________________________
MinGW-users mailing list
MinGW...@lists.sourceforge.net

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
Also: mailto:mingw-use...@lists.sourceforge.net?subject=unsubscribe

Earnie Boyd

unread,
Mar 15, 2012, 10:19:32 AM3/15/12
to MinGW Users List
On Thu, Mar 15, 2012 at 9:42 AM, Christoph Groth <c...@falma.de> wrote:
> Dear MinGW experts,
>
> I'm trying to compile (under Windows 7) our project which is mainly
> implemented in Python but includes several C and a C++ extensions.  I've
> installed the latest MinGW (which is based on GCC 4.6.1) from
> http://mingw.org/.
>
> When I try to build our project in the way which sould work I get an
> error message about g++ not knowing the --output-lib option.
> Unfortunately I could not find any information about this option.  The
> changelog of gcc dosen't seem to mention it.  All I know is that dlltool
> has an option of the same name.
>
> Why and when was --output-lib removed and what to do to replace it?

It should be --out-implib.

--
Earnie
-- https://sites.google.com/site/earnieboyd

Keith Marshall

unread,
Mar 15, 2012, 11:15:57 AM3/15/12
to MinGW Users List
On 15 March 2012 13:42, Christoph Groth wrote:
> When I try to build our project in the way which sould work

You think?

> I get an
> error message about g++ not knowing the --output-lib option.

There is no such option, (and AFAIK never has been).

> Unfortunately I could not find any information about this option.  The
> changelog of gcc dosen't seem to mention it.  All I know is that dlltool
> has an option of the same name.

dlltool is not gcc/g++; dlltool's options are irrelevant.

> Why and when was --output-lib removed and what to do to replace it?

It was never present in the first place; gcc/g++ doesn't create libraries
(in the traditional static library sense). The option to specify the name
for the output file is '-o filename'. By default, output is an executable;
if you want a shared object (DLL) you also specify '-shared'. (When
you create such a shared object, you may also elect to create an
import library, by adding '-Wl,-out-implib=libname'; this is primarily a
convenience, to allow you to link executables which depend on the DLL
without having the DLL itself in the library search path, but it will still
need to be present at run-time).

If you need a static library, (which I suspect you don't), then you add
the '-c' option when you compile each separate object file, then you
use a different tool (ar) to collect these into a library.

--
Regards,
Keith.

Christoph Groth

unread,
Mar 16, 2012, 9:09:30 AM3/16/12
to mingw...@lists.sourceforge.net
Keith Marshall writes:

> On 15 March 2012 13:42, Christoph Groth wrote:
>> When I try to build our project in the way which sould work
>
> You think?

Yes, because we are using distutils which is the official way of
building Python packages. Distutils has explicit support for MinGW.
But apparently this part of it is not too well maintained.

There seem to be no other projects that care about the ability of
distutils to compile C++ python extensions with MinGW.

Thank you for your explanations. I will try whether they solve our
problem as soon as I have access to a computer running windows again.

Christoph

Keith Marshall

unread,
Mar 16, 2012, 6:42:33 PM3/16/12
to mingw...@lists.sourceforge.net
On 16/03/12 13:09, Christoph Groth wrote:
> Keith Marshall writes:
>> On 15 March 2012 13:42, Christoph Groth wrote:
>>> When I try to build our project in the way which sould work
>>
>> You think?
>
> Yes, ...

Really? Why?

> ...because we are using distutils which is the official way of


> building Python packages. Distutils has explicit support for MinGW.

Surely this is irrelevant? Why would you expect a build procedure to
work, when that procedure specifies an option (--output-lib) to g++,
when g++ has never supported this option?

> But apparently this part of it is not too well maintained.

--output-lib is a dlltool option, not a g++ option. Modern GCC mostly
obviates the need for dlltool, so yeah, it possibly doesn't receive a
lot of development attention today.

--
Regards,
Keith.

Christoph Groth

unread,
Mar 19, 2012, 10:51:28 AM3/19/12
to mingw...@lists.sourceforge.net
Keith Marshall writes:

> On 15 March 2012 13:42, Christoph Groth wrote:
>> Why and when was --output-lib removed and what to do to replace it?
>

> (...)


> (When you create such a shared object, you may also elect to create an
> import library, by adding '-Wl,-out-implib=libname'; this is primarily
> a convenience, to allow you to link executables which depend on the
> DLL without having the DLL itself in the library search path, but it
> will still need to be present at run-time).

Replacing "--output-lib name" with "-out-implib=name" worked. Thanks a
lot! There is however another problem... (See other thread.)

Christoph

Reply all
Reply to author
Forward
0 new messages