Trouble with specs

classic Classic list List threaded Threaded
36 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Trouble with specs

Kirk Joppy
I am trying to build a small test program that uses some boost
headers. I can get MinGW to find the headers through Code::Blocks but
not from the command line, and I'm trying to figure out why. I've
installed boost on my machine at H:\boost_1_53_0 with the header files
at H:\boost_1_53_0\boost.

I have installed MinGW and MSYS and put "H:\MinGW\bin" into my system
PATH. I also dumped a specs file and edited the cpp section as
follows:

*cpp:
%{posix:-D_POSIX_SOURCE} %{mthreads:-D_MT} -I H:/boost_1_53_0
%{pthread:-D_REENTRANT} %{!no-pthread: }

I put this file in H:\mingw\lib\gcc\mingw32\4.7.2\

Now, in a command session I navigate to the directory containing my
main.cpp and do the following

> g++ main.cpp

I get "fatal error: boost/property_tree/json_parser.hpp: No such file
or directory". However if I do

> g++ -I H:/boost_1_53_0 main.cpp

the program compiles fine. This would seem to indicate that my
addition to specs isn't being detected. What gives?

I note that if I re-dump specs I get the version _without_ my addition.

###

One more thing. If I instead do this

> gcc -I H:\boost_1_53_0 main.cpp

I get a chain of errors that look like this:

"C:\Users\kjoppy\AppData\Local\Temp\ccsceEk9.o:main.cpp:(.text+0x198):
undefined reference to 'std::string::operator=(char const*)'

I understand that this is due to gcc not linking to std. Is it ok to
just use g++ or do I need to use gcc and set up linking to std?

###

My end goal here is to patch a large open source project that I didn't
write myself. The author of that project was kind enough to distribute
configure and make files. Therefore, once I sort out this and one
other dependency issue I will try to build the project using MSYS to
invoke configure and make. I'll probably be bugging you guys at that
time, so I would like to indicate now that I am very interested
contributing to the documentation on how to do this :)

Thank you very much
kjoppy

------------------------------------------------------------------------------
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev
_______________________________________________
MinGW-users mailing list
[hidden email]

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:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: Trouble with specs

Eli Zaretskii
> Date: Sat, 22 Jun 2013 03:06:02 -0700
> From: Kirk Joppy <[hidden email]>
>
> I am trying to build a small test program that uses some boost
> headers. I can get MinGW to find the headers through Code::Blocks but
> not from the command line, and I'm trying to figure out why. I've
> installed boost on my machine at H:\boost_1_53_0 with the header files
> at H:\boost_1_53_0\boost.

Instead of fighting an uphill battle against GCC, why not install
Boost in the tree where GCC already looks for its headers and
libraries?  That is, put the headers in H:\MinGW\include, the
libraries in H:\MinGW\lib, etc.  The base names of Boost files are
unlikely to conflict with any existing header file, so you shouldn't
need to segregate them.

------------------------------------------------------------------------------
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev
_______________________________________________
MinGW-users mailing list
[hidden email]

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:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: Trouble with specs

Kirk Joppy
In reply to this post by Kirk Joppy
> Instead of fighting an uphill battle against GCC, why not install
> Boost in the tree where GCC already looks for its headers and
> libraries?  That is, put the headers in H:\MinGW\include, the
> libraries in H:\MinGW\lib, etc.  The base names of Boost files are
> unlikely to conflict with any existing header file, so you shouldn't
> need to segregate them.

Thanks for this simple solution. I tried that and it worked, of course.

My reasoning for not stopping at that solution is two fold. First, I'm
new to C++ (about a month) and I am not locked into one tool set.
Depending on how my adventure with MinGW/MSYS/Code::Blocks goes I may
or may not stick with it. It would be nice if I didn't have to rebuild
all my dependencies if I switch to MSVC, for example. (Realistically I
don't think I'm going to go to MSVC but that was my reasoning).

The second part is that because I'm new, I'm trying to actually
understand the guts of these tools as much as I can. If the specs file
exists it must be there for a good reason and I'd like to understand
how to use it. My end goal is to build a very large open source
project that depends on wxWidgents and some stuff from boost. The
project is distributed with a configure and make file. I would like to
get enough understanding of all these tools so that I can successfully
build that project.

Can anyone offer suggestions on how to get library finding through
specs working? What common mistakes might I be making here?

-kjoppy

------------------------------------------------------------------------------
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev
_______________________________________________
MinGW-users mailing list
[hidden email]

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:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: Trouble with specs

Eli Zaretskii
> Date: Sat, 22 Jun 2013 03:58:00 -0700
> From: Kirk Joppy <[hidden email]>
>
> My reasoning for not stopping at that solution is two fold. First, I'm
> new to C++ (about a month) and I am not locked into one tool set.
> Depending on how my adventure with MinGW/MSYS/Code::Blocks goes I may
> or may not stick with it. It would be nice if I didn't have to rebuild
> all my dependencies if I switch to MSVC, for example. (Realistically I
> don't think I'm going to go to MSVC but that was my reasoning).

If you do go to MSVC, it will most probably be installed into a
different tree anyway.  As for rebuilding the dependencies then, I
would suggest to rebuild them nonetheless, since different compilers
have different ABIs, certainly for C++.

> Can anyone offer suggestions on how to get library finding through
> specs working? What common mistakes might I be making here?

I think you need to explicitly instruct GCC to use your specs file, by
using the -specs=FILE command-line switch.  If you don't do that, GCC
will use its internal specs.

------------------------------------------------------------------------------
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev
_______________________________________________
MinGW-users mailing list
[hidden email]

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:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: Trouble with specs

Kirk Joppy
In reply to this post by Kirk Joppy
> I think you need to explicitly instruct GCC to use your specs file, by
> using the -specs=FILE command-line switch.  If you don't do that, GCC
> will use its internal specs.

Allow me to list what I've tried with corresponding results.

specs contains the following entry

*cpp:
%{posix:-D_POSIX_SOURCE} %{mthreads:-D_MT} %{pthread:-D_REENTRANT}
%{!no-pthread: } -I H:/boost_1_53_0

Starting in the directory containing my cpp file...

> g++ -specs=H:\MinGW\lib\gcc\mingw32\4.7.2\specs main.cpp
leads to "fatal error: boost/property_tree/json_parser.hpp: No such
file or directory"

> g++ -specs=H:/MinGW/lib/gcc/mingw32/4.7.2/specs main.cpp
leads to "fatal error: boost/property_tree/json_parser.hpp: No such
file or directory"
(This is the same as the first with / instead of \)

I thought perhaps this isn't working because I'm invoking g++ instead
of gcc, as the documentation indicates that specs is used by gcc. Thus
I tried with gcc

> gcc -specs=H:\MinGW/lib\gcc\mingw32\4.7.2\specs main.cpp
leads to "fatal error: boost/property_tree/json_parser.hpp: No such
file or directory"

> gcc -specs=H:/MinGW/lib/gcc/mingw32/4.7.2/specs main.cpp
leads to "fatal error: boost/property_tree/json_parser.hpp: No such
file or directory"

Now I figured maybe the specs file needs to have \ instead of / so I
changed it to read

*cpp:
%{posix:-D_POSIX_SOURCE} %{mthreads:-D_MT} %{pthread:-D_REENTRANT}
%{!no-pthread: } -I H:\boost_1_53_0

and got the same errors. As soon as I add -I H:/boost_1_53_0 to the
command line it works fine. There has got to be a simple explanation
for this, right?

------------------------------------------------------------------------------
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev
_______________________________________________
MinGW-users mailing list
[hidden email]

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:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: Trouble with specs

Óscar Fuentes
In reply to this post by Kirk Joppy
Kirk Joppy <[hidden email]> writes:

> My reasoning for not stopping at that solution is two fold. First, I'm
> new to C++ (about a month) and I am not locked into one tool set.
> Depending on how my adventure with MinGW/MSYS/Code::Blocks goes I may
> or may not stick with it. It would be nice if I didn't have to rebuild
> all my dependencies if I switch to MSVC, for example. (Realistically I
> don't think I'm going to go to MSVC but that was my reasoning).

As Eli says, if you switch to MSVC++ you have to rebuild boost with that
compiler. More specifically, with the MSVC++ version you would be using.
Same for major GCC releases (i.e. 4.7/4.8 etc) or even for the same GCC
release configured with incompatible options (DW2/sjlj exception model,
etc.)

> The second part is that because I'm new, I'm trying to actually
> understand the guts of these tools as much as I can. If the specs file
> exists it must be there for a good reason and I'd like to understand
> how to use it.

The specs file is not a configuration file for the final user to tinker
on. It is mostly for platform-specific configuration, the sort of work
the MinGW folks do for you.

What you want must be achieved the same way other users do: either by
installing the headers and libraries on a path that the toolset already
knows about or by explicitly telling the build process of your project
where to find the required libraries.

Editing the specs file is the most complicated and error prone method of
achieving what you want.

> My end goal is to build a very large open source
> project that depends on wxWidgents and some stuff from boost. The
> project is distributed with a configure and make file. I would like to
> get enough understanding of all these tools so that I can successfully
> build that project.

Again, the configure&make method shall *never* require (nor even
mention) to edit the specs file. It usually provides a method for
telling where the required libraries are, if they are not installed on
some standard location.

OTOH, if you wish to use the configure&make build for that project,
MSVC++ is not an option because it is almost certain that the configure
script and the accompanying Makefiles doesn't know how to drive the MS
toolset.

> Can anyone offer suggestions on how to get library finding through
> specs working? What common mistakes might I be making here?

Forget it. Make yourself familiar with the standard methods for building
projects and that will do, as it does for 99.99% of the people out
there. Tinkering with the specs file is like opening a can of worms.


------------------------------------------------------------------------------
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev
_______________________________________________
MinGW-users mailing list
[hidden email]

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:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: Trouble with specs

Keith Marshall-3
In reply to this post by Eli Zaretskii
On 22/06/13 12:43, Eli Zaretskii wrote:
> I think you need to explicitly instruct GCC to use your specs file, by
> using the -specs=FILE command-line switch.  If you don't do that, GCC
> will use its internal specs.

No, this is not the case.  GCC's documentation isn't entirely clear on
the subject, but an external file called 'specs', provided it is in the
correct directory, will *always* override the built-in specs in their
entirety, *without* requiring the '-specs=FILE' option.

   $ g++ --version
   g++.exe (GCC) 4.7.2
   Copyright (C) 2012 Free Software Foundation, Inc.
   ...

   $ g++ -v -c nul.cpp
   Using built-in specs.
   COLLECT_GCC=c:\mingw\bin\g++.exe
   ...

   $ gcc -dumpspecs > /mingw/lib/gcc/mingw32/4.7.2/specs

   $ g++ -v -c nul.cpp
   Reading specs from c:/mingw/bin/../lib/gcc/mingw32/4.7.2/specs
   COLLECT_GCC=c:\mingw\bin\g++.exe
   ...

The '-specs=foo' option *augments* the built-in specs, by first parsing
the built-in specs, then those defined in 'foo'.  I prefer to describe
this as augmenting rather than overriding the built-in specs, because
only those spec strings from the built-in set which are explicitly
redefined in 'foo' will be overridden; any built-in specs which are not
so redefined will remain in effect.

I don't know why the OP's external specs file is being ignored, unless
he hasn't saved it in the correct place for gcc/g++ to find it.  For
further advice see: http://www.mingw.org/wiki/SpecsFileHOWTO  (I suggest
you read both the main article, and the follow-up comments).

--
Regards,
Keith.

------------------------------------------------------------------------------
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev
_______________________________________________
MinGW-users mailing list
[hidden email]

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:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: Trouble with specs

Kirk Joppy
In reply to this post by Óscar Fuentes
> As Eli says, if you switch to MSVC++ you have to rebuild boost with that
> compiler. More specifically, with the MSVC++ version you would be using.
> Same for major GCC releases (i.e. 4.7/4.8 etc) or even for the same GCC
> release configured with incompatible options (DW2/sjlj exception model,
> etc.)

Thanks for this information. I got the idea of trying to make shared
resources from this HOWTO on the MinGW website

http://www.mingw.org/wiki/IncludePathHOWTO

Near the bottom there is a list of three ways you might try to deal
with external resources. I went with #3 because it appealed to my
tastes. You are basically saying that #3 doesn't actually work.

> The specs file is not a configuration file for the final user to tinker
> on. It is mostly for platform-specific configuration, the sort of work
> the MinGW folks do for you.

> What you want must be achieved the same way other users do: either by
> installing the headers and libraries on a path that the toolset already
> knows about or by explicitly telling the build process of your project
> where to find the required libraries.

Ok, I'm very glad you're telling me this because this HOWTO

http://www.mingw.org/wiki/SpecsFileHOWTO

really makes it seem like editing specs is kosher.

> Editing the specs file is the most complicated and error prone method of
> achieving what you want.

This needs to be indicated in the documentation. As it stands that
specs HOWTO makes it sound like editing specs is a perfectly fine
idea.

> Forget it. Make yourself familiar with the standard methods for building
> projects and that will do, as it does for 99.99% of the people out
> there. Tinkering with the specs file is like opening a can of worms.

I'm really surprised by this given the existence of official
documentation on editing specs. I'll go with your solution for now
until someone else pipes in. Thanks.

------------------------------------------------------------------------------
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev
_______________________________________________
MinGW-users mailing list
[hidden email]

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:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: Trouble with specs

Keith Marshall-3
In reply to this post by Óscar Fuentes
On 22/06/13 20:39, Óscar Fuentes wrote:
> The specs file is not a configuration file for the final user to tinker
> on. It is mostly for platform-specific configuration, the sort of work
> the MinGW folks do for you.

Once again, this is not (entirely) true.  The MinGW folks *don't* tweak
the specs for you.  We never have; our stock distribution, since GCC-4
came on the scene, has always simply used the built-in (default) specs;
prior to GCC-4, IIRC, we shipped the default specs file, from upstream.

> What you want must be achieved the same way other users do: either by
> installing the headers and libraries on a path that the toolset already
> knows about or by explicitly telling the build process of your project
> where to find the required libraries.

I don't disagree with the advice to follow this approach; however, to
say that the OP *must* do it this way is too strong, (and is untrue).

> Editing the specs file is the most complicated and error prone method of
> achieving what you want.

We must certainly advocate extreme caution, if adopting this approach; a
messed up specs file can break your installation, in interesting ways.
Nevertheless, it is possible to achieve the OP's objective, in this way;
both GCC's manual, and our wiki, document the technique.  I use it, as a
matter of routine, to segregate my add-on libraries and their headers
from those supplied with the GCC compiler suite itself.

--
Regards,
Keith.

------------------------------------------------------------------------------
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev
_______________________________________________
MinGW-users mailing list
[hidden email]

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:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: Trouble with specs

Kirk Joppy
> I don't disagree with the advice to follow this approach; however, to
> say that the OP *must* do it this way is too strong, (and is untrue).

Ok now I get the picture. This technique is a bit tricky, so some
folks are saying "don't do it" while other folks (Keith) are saying
"do it, but be careful."

Keith, I just noticed your extended comments on the wiki post. Thanks
for doing that. I'll read it and see if I can figure out why my specs
file doesn't seem to be doing what I want. Could this have anything to
do with the difference between invoking g++ as opposed to gcc? I went
with g++ because gcc doesn't know about std.

By the way, this would be a good opportunity to clean up that howto.
It seems like your comments at the bottom are really important.
Perhaps those should be moved upwards...

------------------------------------------------------------------------------
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev
_______________________________________________
MinGW-users mailing list
[hidden email]

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:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: Trouble with specs

Óscar Fuentes
In reply to this post by Keith Marshall-3
Hello Keith, some clarifications below.

Keith Marshall
<[hidden email]>
writes:

> On 22/06/13 20:39, Óscar Fuentes wrote:
>> The specs file is not a configuration file for the final user to tinker
>> on. It is mostly for platform-specific configuration, the sort of work
>> the MinGW folks do for you.
>
> Once again, this is not (entirely) true.  The MinGW folks *don't* tweak
> the specs for you.  We never have; our stock distribution, since GCC-4
> came on the scene, has always simply used the built-in (default) specs;
> prior to GCC-4, IIRC, we shipped the default specs file, from upstream.

I tried to say that tweaking the specs file is what the
developers/packagers would do, not that you are doing it, actually.

>> What you want must be achieved the same way other users do: either by
>> installing the headers and libraries on a path that the toolset already
>> knows about or by explicitly telling the build process of your project
>> where to find the required libraries.
>
> I don't disagree with the advice to follow this approach; however, to
> say that the OP *must* do it this way is too strong, (and is untrue).

"must" here means "it must be possible to do it on a much more simple
and robust way by some other method."

>> Editing the specs file is the most complicated and error prone method of
>> achieving what you want.
>
> We must certainly advocate extreme caution, if adopting this approach; a
> messed up specs file can break your installation, in interesting ways.
> Nevertheless, it is possible to achieve the OP's objective, in this way;
> both GCC's manual, and our wiki, document the technique.  I use it, as a
> matter of routine, to segregate my add-on libraries and their headers
> from those supplied with the GCC compiler suite itself.

Yes, it is possible to achieve what the OP wants by using a specs file,
as it is by changing the GCC sources. But please keep in mind that the
OP described himself as a beginner on using C++ toolsets (and probably
on using compilers too.) I'm convinced that he chose the specs way as a
consequence of his inexperience and the sooner we put him on the right
path, the better.


------------------------------------------------------------------------------
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev
_______________________________________________
MinGW-users mailing list
[hidden email]

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:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: Trouble with specs

Keith Marshall-3
In reply to this post by Kirk Joppy
On 22/06/13 21:19, Kirk Joppy wrote:

>> As Eli says, if you switch to MSVC++ you have to rebuild boost with that
>> compiler. More specifically, with the MSVC++ version you would be using.
>> Same for major GCC releases (i.e. 4.7/4.8 etc) or even for the same GCC
>> release configured with incompatible options (DW2/sjlj exception model,
>> etc.)
>
> Thanks for this information. I got the idea of trying to make shared
> resources from this HOWTO on the MinGW website
>
> http://www.mingw.org/wiki/IncludePathHOWTO
>
> Near the bottom there is a list of three ways you might try to deal
> with external resources. I went with #3 because it appealed to my
> tastes. You are basically saying that #3 doesn't actually work.

In the context you've quoted, it is doubtful if it would; you can't
share libraries, (particularly C++ libraries between compilers with
differing ABIs.

In the general case, where the intent is simply to segregate add-on
libraries from the core set, but while maintaining ABI consistency, #3
WJFFM.

--
Regards,
Keith.

------------------------------------------------------------------------------
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev
_______________________________________________
MinGW-users mailing list
[hidden email]

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:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: Trouble with specs

Óscar Fuentes
In reply to this post by Kirk Joppy
Kirk Joppy <[hidden email]> writes:

>> As Eli says, if you switch to MSVC++ you have to rebuild boost with that
>> compiler. More specifically, with the MSVC++ version you would be using.
>> Same for major GCC releases (i.e. 4.7/4.8 etc) or even for the same GCC
>> release configured with incompatible options (DW2/sjlj exception model,
>> etc.)
>
> Thanks for this information. I got the idea of trying to make shared
> resources from this HOWTO on the MinGW website
>
> http://www.mingw.org/wiki/IncludePathHOWTO
>
> Near the bottom there is a list of three ways you might try to deal
> with external resources. I went with #3 because it appealed to my
> tastes. You are basically saying that #3 doesn't actually work.

That paragraph is about using -I and -L on gcc invocations, not really
about using the specs file. Furthermore, it ends with:

  (While this may still be achieved by appropriate customisation of the
  GCC Specs File, or by appropriately specifying the CPATH and related
  environment variables, the additional complexity, and maintenance
  overhead, may be considered unacceptable to many users)

That's a clear warning, but just in case I'll translate it to blunt
English: "don't do it unless you have a lot of frustration endurance and
lots of spare time to throw at it." :-)

>> The specs file is not a configuration file for the final user to tinker
>> on. It is mostly for platform-specific configuration, the sort of work
>> the MinGW folks do for you.
>
>> What you want must be achieved the same way other users do: either by
>> installing the headers and libraries on a path that the toolset already
>> knows about or by explicitly telling the build process of your project
>> where to find the required libraries.
>
> Ok, I'm very glad you're telling me this because this HOWTO
>
> http://www.mingw.org/wiki/SpecsFileHOWTO
>
> really makes it seem like editing specs is kosher.

Unfortunately, a few settings that some advanced MinGW users appreciate
(like using different runtime versions, (if you don't know what that is,
you don't need to know)) require to tinker with the specs file. I'm sure
that the MinGW developers would like to provide simpler methods for
using those settings, but for now it is what we have.

As a general rule, you don't need to change the specs file unless you
have special needs (and from the description you provided about your
project, your requirements are fairly ordinary.)


------------------------------------------------------------------------------
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev
_______________________________________________
MinGW-users mailing list
[hidden email]

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:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: Trouble with specs

Kirk Joppy
In reply to this post by Óscar Fuentes
I have discovered the error. The issue was that per the documentation I added

*cpp:
%{posix:-D_POSIX_SOURCE} %{mthreads:-D_MT} %{pthread:-D_REENTRANT}
%{!no-pthread: } -I H:/boost_1_53_0

However, to get g++ to work with my external library I had to do this

*cc1plus:
-I H:/boost_1_53_0

Adding that entry now allows me to invoke g++ without -I options and
get my external boost headers properly found. Thanks, Keith, for your
detailed documentation. It really should be promoted to the main part
of the howto.

Oscar, now that I understand both ways of doing this and can see why
editing specs could be tricky I'll probably go with your suggested
method. That said, I'm really glad that Keith took the time to explain
what was going on. Most people asking about details like this are
computer literate and can make logical decisions provided with
accurate information. You were trying to keep me from doing
destructive things to myself, but I'd say in my experience that a user
doing something "because they said so" is the most destructive
instrument of all.

------------------------------------------------------------------------------
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev
_______________________________________________
MinGW-users mailing list
[hidden email]

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:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: Trouble with specs

Keith Marshall-3
In reply to this post by Óscar Fuentes
On 22/06/13 21:40, Óscar Fuentes wrote:

> Hello Keith, some clarifications below.
>
> Keith Marshall writes:
>
>> On 22/06/13 20:39, Óscar Fuentes wrote:
>>> What you want must be achieved the same way other users do: either by
>>> installing the headers and libraries on a path that the toolset already
>>> knows about or by explicitly telling the build process of your project
>>> where to find the required libraries.
>>
>> I don't disagree with the advice to follow this approach; however, to
>> say that the OP *must* do it this way is too strong, (and is untrue).
>
> "must" here means "it must be possible to do it on a much more simple
> and robust way by some other method."
I guess it's because English isn't your first language, that what you
actually said isn't what you really meant.

>>> Editing the specs file is the most complicated and error prone method of
>>> achieving what you want.
>>
>> We must certainly advocate extreme caution, if adopting this approach; a
>> messed up specs file can break your installation, in interesting ways.
>> Nevertheless, it is possible to achieve the OP's objective, in this way;
>> both GCC's manual, and our wiki, document the technique.  I use it, as a
>> matter of routine, to segregate my add-on libraries and their headers
>> from those supplied with the GCC compiler suite itself.
>
> Yes, it is possible to achieve what the OP wants by using a specs file,
> as it is by changing the GCC sources. But please keep in mind that the
> OP described himself as a beginner on using C++ toolsets (and probably
> on using compilers too.) I'm convinced that he chose the specs way as a
> consequence of his inexperience and the sooner we put him on the right
> path, the better.
We were all beginners, at one time.  I'd been writing software for
around 25 years, before my first foray into specs file customisation,
and I approached that with quite some trepidation; it was worth it, in
the end.  Yes, we must advise caution, but the OP seemed to have a
reasonable idea of what is required.  We should not discourage such
experimentation; it's how we all learn.

FWIW, the attached patch shows how I modified my specs file, to achieve
a similar objective to the OP's.

--
Regards,
Keith.

------------------------------------------------------------------------------
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev
_______________________________________________
MinGW-users mailing list
[hidden email]

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:[hidden email]?subject=unsubscribe

mingw32-specs.diff (1K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Trouble with specs

Keith Marshall-3
In reply to this post by Kirk Joppy
On 22/06/13 21:31, Kirk Joppy wrote:
> Keith, I just noticed your extended comments on the wiki post. Thanks
> for doing that. I'll read it and see if I can figure out why my specs
> file doesn't seem to be doing what I want. Could this have anything to
> do with the difference between invoking g++ as opposed to gcc?

No; gcc and g++ share a common specs file.

> I went with g++ because gcc doesn't know about std.

You are right to use g++, when compiling C++ code; gcc may compile it,
but it won't invoke the linker correctly.  (However, if the source file
is appropriately named, gcc *should* cope with namespace std just fine,
when compiling to object format).

> By the way, this would be a good opportunity to clean up that howto.
> It seems like your comments at the bottom are really important.
> Perhaps those should be moved upwards...

I agree.  I've considered rewriting that article, but I've never found a
suitable round tuit.  I'll get to it one day, if no one else beats me to
the post.

--
Regards,
Keith.

------------------------------------------------------------------------------
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev
_______________________________________________
MinGW-users mailing list
[hidden email]

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:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: Trouble with specs

Kirk Joppy
> No; gcc and g++ share a common specs file.

That's odd to me because putting the -I line in as

*cc1plus:
-I H:/boost_1_53_0

made everything work, whereas it didn't work when I did

*cpp:
%{posix:-D_POSIX_SOURCE} %{mthreads:-D_MT} %{pthread:-D_REENTRANT}
%{!no-pthread: } -I H:/boost_1_53_0

Perhaps I do not understand exactly what these parameters mean.

------------------------------------------------------------------------------
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev
_______________________________________________
MinGW-users mailing list
[hidden email]

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:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: Trouble with specs

Keith Marshall-3
On 22/06/13 23:00, Kirk Joppy wrote:
>> No; gcc and g++ share a common specs file.
>
> That's odd to me because putting the -I line in as
>
> *cc1plus:
> -I H:/boost_1_53_0

You need it here, for g++

> made everything work, whereas it didn't work when I did
>
> *cpp:
> %{posix:-D_POSIX_SOURCE} %{mthreads:-D_MT} %{pthread:-D_REENTRANT}
> %{!no-pthread: } -I H:/boost_1_53_0

You *also* need it here, if you want gcc to search that same include
path; if you consult the patch I attached earlier, you'll see that I
have my %(local_includes) in *both* of the above; I also appended
%(local_libs) to *link_libgcc, to add the associated -L path.

--
Regards,
Keith.

------------------------------------------------------------------------------
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev
_______________________________________________
MinGW-users mailing list
[hidden email]

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:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: Trouble with specs

Kirk Joppy
> You *also* need it here, if you want gcc to search that same include
path;

Ok, that makes sense. Am I correct that in using C++ I'm going to be
only invoking g++ and not gcc?

I'm currently trying to build boost in something approaching sane way.
Thanks for all your help up until now. I will probably post again
later once I have all my libraries installed and get to actually
building the project.

By the way I really appreciate your willingness to tell it like it is
rather than trying to scare me into doing the right thing. That's very
valuable.

------------------------------------------------------------------------------
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev
_______________________________________________
MinGW-users mailing list
[hidden email]

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:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: Trouble with specs

Peter Rosin
In reply to this post by Óscar Fuentes
On 2013-06-22 21:39, Óscar Fuentes wrote:
> OTOH, if you wish to use the configure&make build for that project,
> MSVC++ is not an option because it is almost certain that the configure
> script and the accompanying Makefiles doesn't know how to drive the MS
> toolset.

If you actually tried it, I think you'd be surprised how well it works.
But you are right, since noone has tried it for most projects you are
probably going to be bitten be some annoying problem when you do try it
with a random project. But the problems are more often found in the
code, like inline assembly in AT&T syntax, or the assumed presence of
some headers or library functions provided by mingwex, and less often
in the build system itself. Or perhaps better expressed; the problems
in the build system are often easier to fix than the code problems.

But I digress.

Cheers,
Peter


------------------------------------------------------------------------------
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev
_______________________________________________
MinGW-users mailing list
[hidden email]

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:[hidden email]?subject=unsubscribe
12