I'm trying to install CurlPP, but it seems to put "-Os" in the CXXFLAGS. Then, it tries to remove the optimization flag, but the regex is -O[0-9] in automake doesn't match the 's'. This is causing builds to fail.
Where does this "-Os" come from? Is this a legitimate optimization flag, or what?
How can I change CXXFLAGS on my machine with homebrew?
-Os is optimise for size. It's pretty standard on any C compiler to be honest. Perhaps just change the regex?
Thank you, I have the same problem, but I had no idea why it complains about some 's' in command line!
The fix is really simple: run brew edit curlpp, then insert line
ENV.remove_from_cflags(/-O./)
at the beginning of the install function in the script. That turns off the optimization though, so you may find better solution. But the package installs well.
Related
Goal
When I run the command:
gcc -ggdb -std=c99 -Wall -Werror hello.c -lcs50 -o test.exe from the root directory
I am able to build the test.exe file and when I run test.exe all is well (thanks to this post by Manohar Reddy Poreddy)
However all of those flags are a little bit cumbersome and I think it would great to condense them into a 'make' command or similar. How would I do this on windows?
Context
GCC, G++ and GDB all seem to be correctly linked (I used chocolatey which paths everything automatically)
Okay so I found what I was looking for.
I hope this answer can help others. Turns out the utility is called 'make' (no surprises). In your directory you essentially create a 'makefile' where you can include your command line arguments which saves on repeated typing in the command line for each compile.
Here is an excellent response on how to install 'make' for windows and was perfect for my use case as a Chocolatey user.
I also found this resource which helps newcomers begin to get their head round GCC which I highly recommend if you're coming into this like I was and felt completely out of your depth.
The title says it all really, I run gfortran to compile a simple test fortran program, it compiles with no errors; but when I run ls to look at the output, there is no executable created. I've tried with the -o option set as well.
The fotran program is a simple hello world
program test1
implicit none
print *, "Hello World!"
end program test1
(The gfortran I'm using is from the mingw release; I have aliased gfortran to c:/mingw/bin/gfortran.exe within powershell, but the same problem happens if I call it explicitly)
Has anyone had this problem before? I thought it might be a permissions issue but I can create files from powershell just fine (unless gfortran needs additional permissions for some reason?). Any help greatly appreciated, thanks :)
Turns out simply aliasing the path to the compiler doesn't work in powershell for MinGW, adding the mingw bin directory to the path is necessary and solved my problem as #cup suggested in the comments. Thanks everyone :)
I just happened to have the same problem that you described but two years later ...
I found that I just need to call the program as ./test.exe instead of test.exe, as I would have done with MS-DOS. That way I do not have to change the path if I work in a different folder.
In my Makefile, I want to link to a library only if it is installed on the machine. So, for example if the library is hwloc, I want to do the following:
xfoo : foo.o
if (hwloc installed)
gcc foo.o -o $# -lhwloc
else
gcc foo.o -o $#
Is there anyway to do something like this? i.e. Is it possible to check if a specific library is installed and use that as a condition in a Makefile?
Here's the wrong answer:
xfoo : foo.o
if (hwloc installed); then gcc foo.o -o $# -lhwloc; else gcc foo.o -o $#; fi
Commands executed from a Makefile do not have to be just simple, single commands. Anything that a shell can execute, can be invoked from a Makefile. Including an entire script, sandwiched into one line.
Here's the right answer:
However, the above approach is the wrong one. You will find that many free software packages do this kind of thing all the time: conditionally link in a library, if it's available.
But the way that it's done is by running a separate configure script, before running make. Go grab the source tarball to a random free software package, of your choosing, and read the installation instructions. They will all tell you to run the configure script first, before running make.
A crushing majority of free software packages use the GNU toolchain to create their build system -- the configure script, and the Makefile. The GNU toolchain consists of autoconf and automake tools (also libtool in many cases). Go Google these, for more information.
There are also a few other, less popular toolchains, but the GNU toolchain is the most frequently one used, for this sort of a thing. So, to do something along the lines of what you're trying to do, the way this gets typically done is:
In the configure.ac file:
AC_CHECK_LIB(hwloc,some_function_in_the_hwloc_library,[LINK_HWLOC=-lhwloc])
AC_SUBST(LINK_HWLOC)
In the Makefile.am file:
hwloc_LDADD=#LINK_HWLOC#
That's it. That's the way this is done the countless number of times most free software packages need to do this exact same thing. autoconf and automake will take care of writing the shell script and the makefile, that implements this.
I don't have access to a Linux machine at the moment so pardon me my answer will be untested.
I will respectfully disagree with both of my predecessors.
First, using autotools to amend an existing Makefile is a bad idea. Autotools are made to avoid worrying about creating a good Makefile in a simple use case. It's as if OP asked "How to change + to - in my Python script" and the answer was "write a shell script to modify the script, save it in temporary file and execute the file"
Second answer, why do something manually when it can be painlessly done automatically?
So, IMHO the correct answer is, this is the exact use case for $(wildcard):
xfoo: foo.o $(wildcard libhwloc.a)
gcc $(patsubst lib%.a, -l%, $^) -o $#
Note: the library is installed or not ahead of time but not to be made during the build.
If you don't want to get involved with the autotools/etc. for this (which while a reasonable solution is also reasonable to want to avoid for something this simple) and you don't want to have to play guessing games about where people may or may not have this hwloc library installed then the best you can do is to let people turn the feature on manually.
Use three (or four) make variables. USE_HWLOC, HWLOC_LDLIBS, HWLOC_CFLAGS and possibly HWLOC_LDFLAGS.
Then when USE_HWLOC is defined you link against the library and use the other three variables in case they have also been set.
ifdef USE_HWLOC
HWLOC:=-lhwloc
else
HWLOC:=
HWLOC_LDLIBS:=
HWLOC_LDFLAGS:=
HWLOC_CFLAGS:=
endif
xfoo : foo.o
gcc foo.o -o $# $(HWLOC_LDLIBS) $(HWLOC)
While looking at my friend's Makefile, I noticed that he used the install shell command. From what I can tell, the command allows you to install and chmod files with one fell swoop. The command came up in a subsequent conversation of ours, and he said he had heard that the command is considered somewhat archaic, and that developers should use cp, mv, chmod etc. for modern projects.
Strangely, this has been my only encounter with the command. This leads me to believe that the command has indeed been rejected and hence forgotten. Is this true? Is there some sort of security flaw with the program? From my possibly naive point of view, using a single command is always better than using many commands
I suspect the answer is that the install command is pretty much only used in scripts and makefiles (such as the automake makefiles that #Jack Kelly describes), and almost never interactively. Thus people rarely see it 'over someone's shoulder', and it doesn't lodge in their consciousness.
It is however, as you say, pretty much exactly the right tool for this job. The problem is that it's not a POSIX command, so it's wise not to use any terribly exotic options. The version of it used in automake makefiles is supplemented by a distributed shell script if the configure script hasn't convinced itself that the local version is sufficiently compatible.
See the autoconf manual's discussion of portable shell scripting, for some useful tips on this general topic.
Makefiles generated by automake still use it, as evidenced by the line (or similar):
checking for a BSD-compatible install... /usr/bin/install -c
in the output of configure.
I'm trying to make the --dynamic-linker option work with CodeSourcery's ARM cross toolchain. However gcc seems to ignore it, and never adds an interpreter segment in the shared library's ELF. What am I missing to make this work?
I doubt gcc ignores the option. Add -v to the compiler command line to verify that the option is indeed passed to the linker.
More likely, you are using the option incorrectly. --dynamic-linker is taking a =file argument, and you didn't mention that you are passing one.
Edit: as you found out, you have no .interp section in your linker script. However, you should - see this example.