I use VS2015+ wxwideget 3.10 to run a very simple example from wxwidget examples
Yesterday this example was able to run properly but today the example starts to display "Error C1189 #error: "wxUSE_ACTIVEX must be defined." when building it. I didn't change the configuration settings so this thing is quite confusing. Where could be the bugs?
the place where error occured(in chkconf.h):
f/* ensure that MSW-specific settings are defined */
#ifndef wxUSE_ACTIVEX
# ifdef wxABORT_ON_CONFIG_ERROR
# error "wxUSE_ACTIVEX must be defined."
# else
# define wxUSE_ACTIVEX 0
# endif
#endif /* !defined(wxUSE_ACTIVEX) */
my property settings:
additional include directories: $(WXWIN)\include; $(WXWIN)\include\msvc;
additional library directories: $(WXWIN)\lib\vc_x64_lib
First of all, it's completely impossible that something that worked yesterday stopped working today without anything else. You did change something and, of course, only you know what it was.
Second, all wxUSE_XXX constants are defined in include/wx/msw/setup.h which is copied to lib/vc_x64_lib/mswu/wx (or another similar directory depending on debug/release, lib/DLL build settings) during the library build and is found there by by include/msvc/wx/setup.h. So if it's not defined, the first thing to do is to check that this file didn't get changed somehow (maybe accidentally, although I have trouble imagining how this could happen).
Related
This may sound like a very noob question.
I'm trying to implement a UDP-based protocol in the linux kernel. I was following the UDPLite protocol implementation as a reference.
Step 1
I created a new_protocol.c in net/ipv4/
This file has a function
void _init protocol_init(void){*Code here*}
I also used
#include "udp_impl.h"
in this file as I was using some functions from the UDP protocol
Step 2
I modified the file net/ipv4/udp_impl.h to include net/new_protocol.h
Step 3
I created the file include/net/new_protocol.h where I defined the function
void protocol_init(void);
Step 4
Finally, I called the function in net/ipv4/af_inet.c. Also, I gave an include statement in this file for net/new_protocol.h
Now when I try to build the kernel, I get an error saying
undefined reference to `protocol_init()'
What am I missing here? Is my way of including header files incorrect? Do I need to include some info in the makefile to pick up the new net/ipv4/protocol.c?
Do I need to include some info in the makefile to pick up the new net/ipv4/protocol.c?
Yes, you need. Kernel build system doesn't autodetect source files, all of them should be listed explicitely in appropriate Makefile. In you case you need to modify net/ipv4/Makefile.
Makefiles used for kernel build are described in file Documentation/kbuild/makefiles.txt.
I just needed to add protocol.o in the makefile in net/ipv4/
I am trying to port a new module into my project. The module has its own make file. I have no background or experience with the make build system, so I decided to use the following command:
make -f Makefile -f ../newmodule/tbt/makefile
But I get the following errors:
../newmodule/tbt/makefile:14: make/macros.mk: No such file or
directory
../newmodule/tbt/makefile:66: *** target file `all' has both : and :: entries. Stop.
Please correct me if I am wrong; it is my understanding that my first error is because I issued make from my main project, and I need to somehow configure it to look into the directory of ../newmodule/tbt/make to find macros.mk. Would anyone be able to suggest an effective way of addressing this issue? What is the best way to include the contents of ../newmodule/tbt/make folder?
My 2nd error seems to be exactly what make complains about, which is having : and :: in the two make files for the target "all". I can not follow the 2nd make file very closely, but there is not much to the lines that have this target. I am thinking of changing it to My_all, and configure this new variable as the default target of the new module. I am not even sure if my terminology is correct. "all" is called the default target for make right? I have reviewed most of the make file document, but it is 5 am, and I do not recall some things.
I came across this error during compilation of some package under OpenWrt. The problem was in the VERSION declaration in the Makefile.
So, check if you have declared anything with unnecessary spaces or comments after some variable.
Removing the comment or space after variables should work.
Try running two separate make -f myMakefile commands, one from each module directory so that the relative paths work out properly as you have already observed that you current directory when executing make may be part of the problem.
I seem to successfully build a kernel image, but I can not generate all the modules I expect. I expect more modules since I see them enabled in the gconfig window. Here is a copy of my make session. Seems like make goes into the devices directories. I can not figure out why it is not create the .ko files. I expect to see .ko files. I have checked the Makefile in /drivers directory, and I can see that it is configured with a number of lines like
obj-$(CONFIG_PCI) += pci/
Which directs make to build the pci module for instance. I think this implies that I should see a number .ko files. But I do not. I have seen just one .ko file for scsi module. I like to be able to build all of modules selected.
I also verified that a number of mudules are enabled when I issued:
make VARIANT_DEFCONFIG=msm8974_sec_hlte_spr_defconfig msm8974_sec_defconfig SELINUX_DEFCONFIG=selinux_defconfig gconfig
But as I said, I do not see any of them. What am I missing please?
#Subin - Thanks. I just tried make modules_install. I have to mention that I am cross compiling this for an arm target. I believe modules_install is for the purpose of installing the driver for the machine you are on? I got a message about needing to be in root, and I did not proceed. I have been wondering when I need to run it. What does it do exactly please?
Re: the make modules; I have run it before. I'll run it again and post the result. Since I got one .ko file I figured the issue is something different between that one module, and every other one enabled in my config. Here is what I got when I ran make modules:
sansari#ubuntu:~/WORKING_DIRECTORY$ make modules
CHK include/linux/version.h
CHK include/generated/utsrelease.h
make[1]: `include/generated/mach-types.h' is up to date.
CALL scripts/checksyscalls.sh
Building modules, stage 2.
MODPOST 1 modules
Re: your comment on the location of .ko files, I am doing a find to see if perhaps I am not looking at the right place, it only finds the one which was built. Not the other ones. Here is the output:
sansari#ubuntu:~/WORKING_DIRECTORY$ find . -type f -name "*.ko"
./drivers/scsi/scsi_wait_scan.ko
sansari#ubuntu:~/WORKING_DIRECTORY$
Should I perhaps run make v=1, in verbose mode that is? Would that provide more information on why the other modules are not built?
#Gil Hamilton - Thanks. You are right. Here is an excerpt of the .config file:
#
# SCSI support type (disk, tape, CD-ROM)
#
CONFIG_BLK_DEV_SD=y
# CONFIG_CHR_DEV_ST is not set
# CONFIG_CHR_DEV_OSST is not set
# CONFIG_BLK_DEV_SR is not set
CONFIG_CHR_DEV_SG=y
CONFIG_CHR_DEV_SCH=y
CONFIG_SCSI_MULTI_LUN=y
CONFIG_SCSI_CONSTANTS=y
CONFIG_SCSI_LOGGING=y
CONFIG_SCSI_SCAN_ASYNC=y
CONFIG_SCSI_WAIT_SCAN=m
This entry is the only one set to 'm'.
Most device driver modules in the linux kernel build system use a tristate (3-valued) configuration setting. The options are
'n' (don't build at all),
'y' (build and link statically into the main kernel object), and
'm' (build as module for dynamic loading).
The values are determined by the content of .config. The values in .config are usually generated from an existing config file (look in arch/<ARCH>/configs for your <ARCH>). Also check the output of 'make help' for interesting configuration targets.
If you're not seeing the .ko files being created, that indicates the corresponding configuration variable is either set to 'y' or 'n'.
I have written a script to update a table by passing the parameters to the script. It appears to run just fine but throws the following warnings upon execution :
*** Warning:
Problem resolving parameter "ORACLE_CLIENT_VERSION" of "/abinitio/apps30/ste-uat/CitiTech/stdenv/.project.pset":
Parameter:`ORACLE_CLIENT_VERSION' referenced before being defined in pset:`/abinitio/apps30/ste-uat/CitiTech/stdenv/.sandbox.pset'.
Can anyone tell me why these warnings are displayed or how to suppress/hide these warnings ??
I'm not sure but such a variable ("ORACLE_CLIENT_VERSION") is defined in ruby apps. For example, look here at the config.rb file.
If I were you, I would make just a search in your project for such a config file, and define the ORACLE_CLIENT_VERSION there.
Hey, I just Downloaded openvrml from macports
(port install openvrml)
Now I have a Sample program (pretty_print.cpp from openvrml at sourceforge) that begins like this:
# ifdef HAVE_CONFIG_H
# include <config.h>
# endif
# include <openvrml/vrml97_grammar.h>
# include <openvrml/browser.h>
# include <fstream>
...
then in Xcode, I added the following path and check "recursive" for the Header search path and Lib Search Path:
/opt/local/var/macports/software
And all '***.h file not found' errors disappeared, but now I have the following two:
complex.h 943 '__pow_helper' is not a member of std
c++locale.h 71 'vsnprintf' is not a member of std
/Developer/SDKs/MacOSX10.6.sdk/usr/include/c++/4.2.1/complex: In function 'std::complex<_Tp> std::pow(const std::complex<_Tp>&, int)':
/Developer/SDKs/MacOSX10.6.sdk/usr/include/c++/4.2.1/complex:943: error: '__pow_helper' is not a member of 'std'
both errors come from system files.
I wonder what is causing this errors...
Can anyone advice me on how to use openvrml samples on Macs?
thanks in advance.
I've had a similar problem. I defined "recursive" flag for an '/opt/local/include' path. This pulled in some strange c++ headers from boost compatiblity includes.
In general, you do not want "recursive" flag on your include paths.
Try unchecking "recursive" from your paths.
if you put recursive on a path containing boost headers you'll use some random boost headers, which are likely designed to be used in different environment and/or different compiler, instead of standard C++ headers, meaning, for example, you'll include TR1 header instead of standard header. This is likely to be the cause of your problem (it happened to me too).
Just locate the directory which contains the headers you need and put only that in header search path instead of being lazy and using "recursive" flag, since there are a lot of header files which have same name but differ in location only.