I have begun to use GTK(2), and I find that the workings of the library to be very good, but the documentation sucks.
I want to upgrade to GTK3, but it seems I need to install something called packman. That is a difficult philosophical step for me. Why can't I simply download a zip file(s) somewhere?
The documentation uses a lot of words without saying much, and the downloads want you to download stuff OTHER then gtk in order to get gtk. Why don't they simply have a GTK package and let me decide if I need all the other stuff.
Also, I have been reading on forums, even if I do the packman stuff, it still isn't enough for C::B.
Anyway, that is mostly a rant, what I'd really like is a suggestion to an alternative to GTK+.
Here are some of my requirements...
#1, It must NOT be an interpreter. Using Code::Blocks and C, I get an exe file and I'd like to continue that way.
#2 It must be programmable using C. I'd really like to stick wiith C::B, but I guess in a pinch I can use Eclipse (although that is another nightmare I won't get into here.)
#3 GTK requires a bunch of DLL's to be shipped along with the exe file. It would be ideal if the entire target could be included in the single exe without having to rely on external dll's or .net framework or other external stuff.
Any suggestions woule be apreaciated.
Thanks, Mark.
You best bet is to give a look at https://en.wikipedia.org/wiki/List_of_widget_toolkits#High-level_widget_toolkits
If you wan to stick to C and not C++, then Qt is out.
The other that stands out is EFL. I've never used it myself, but it has good reputation and probably your best bet if you want to quit GTK+ and stick to C. However I don't know how easy it is to use it on Windows.
Now about GTK+:
Also, I have been reading on forums, even if I do the packman stuff, it still isn't enough for C::B.
There are people here that use GTK+ with Code::Blocks, so I don't get what kind of problem you're referring to.
Then your other problems:
The documentation uses a lot of words without saying much
Examples?
the downloads want you to download stuff OTHER then gtk in order to get gtk
What you don't get is that GTK+ is more that just the libgtk library. It has dependencies on a lot of other libraries, like glib, cairo, pango, etc. In the past there used to be a bundle or installer to have that installed on Windows, but people would mess up on setting the environment up based on their needs and give up. As the GTK+ manpower for the Windows platform is limited, the GTK+ team delegated the distribution of the GTK+ binaries to the MSYS2 project.
MSYS2 is a popular project that provides a lot of open source software already built for Windows, and solves the problem of building and installing dependencies by hand for the user. This step is made to make installation simpler, not harder. In a handful of commands you have GTK+ and all its dependencies installed for your platform, and can start coding your app. Another command and you have python and the python GTK+ bindings installed and can get started. Want to depend on another popular library? Chances are MSYS already provides it.
Windows has been known for decades to be bad on dependency management. If package management wasn't a a pain point on Windows, then stuff like chocolatey or conan wouldn't exist.
Your philosophical reluctance is merely that: philosophical. Sure GTK+ on Windows isn't perfect. With MSYS2 you will get packages built with gcc so the debug symbols are not compatible with the Visual Studio debugger and you will need to use gdb instead. But on your other question you say you use gcc and loathe Visual Studio, so this should not be a blocker to you.
GTK requires a bunch of DLL's to be shipped along with the exe file. It would be ideal if the entire target could be included in the single exe without having to rely on external dll's or .net framework or other external stuff.
This is not possible for the moment as static compilation of GTK+ isn't supported. The redistribution of an app, however, isn't as easy as I'd like it to be. The best way on Windows to redistribute your app while using MSYS2 is to create a pacman package for your app, listing its dependencies, then call pacman to install your app on an empty directory and tell it to install all your dependencies there too. The result will be a directory that you can redistribute, with a self-contained installation of your app and all its dependencies, GTK+ included.
I am trying to build AWS-CPP SDK on Linux and Windows. It has dependency of OpenSSL, zlib, and libucurl. Although these packages are available on Linux, they are not on Windows. How do I specify the locations of these packages' header files and libraries?
I also have more recently versions of these packages on Linux. How do I override the default paths?
There isn't any special requirements for Windows. As you can see from this: http://docs.aws.amazon.com/sdk-for-cpp/v1/developer-guide/setup.html
Only Linux requires those extra libraries. On Windows, it will use whatever is provided by platform/Visual Studio.
All 3 dependencies are found for Windows - both x32 and x64 bit architectures.
You may also build them from source.
OpenSSL can be found here (and on other sites too):
https://wiki.openssl.org/index.php/Binaries
Zlib is found at :
https://github.com/kiyolee/zlib-win-build
libCurl can be built from source too:
https://curl.se/docs/install.html
Building from source code is necessary, if you want the resulting .LIBs(static) and/or DLLs, to be compatible with your version of Visual C++/Studio(2005-2022).
I am trying to get the micro-coap librarby (https://github.com/1248/microcoap)
to work on my arduino. When I try to compile it in the Arduino IDE, it reports that <sys/socket.h> dependency in main-posix.c can not be found.
Searches for the problem were not helpful, except for some general C++ answer that was hinting that there is no sys/socket.h on Windows. But this should not have anything to do with Arduino right?
I looked at the ethernet library for arduino and there is a socket.h but it is not in a sys directory.
Hope you can help
It seems that the main-posix.c source file is meant to be compile for a UNIX/LINUX based operating system. If you want to use Windows to compile main-posix.c, you can use projects like Cygwin. Arduino does not have <sys/socket.h> dependency needed to compile main-posix.c. Instead open microcoap.ino in the Arduino IDE and compile and flash it to the hardware.
Someone suggested simply taking the file out of the arduino path / deleting it and that worked. As Stefan posted in his answer, it is used to build the library on unix/linux and has no relevance for arduino.
I am working on a GUI application which aims to be portable between different window managers(Gnome and KDE) and platforms(Linux and Windows).
Most of my work is done with C++ / wxWidgets.
I am currently preparing a new development environment.
I find several packages when searching "wx-config":
myusername#domain:~$ wx-config --version
The program 'wx-config' can be found in the following packages:
* libwxbase2.8-dbg
* libwxbase2.8-dev
* libwxbase3.0-dev
* libwxgtk2.8-dbg
* libwxgtk2.8-dev
* libwxgtk3.0-dev
Try: sudo apt-get install
Could anyone explain to me what is the difference between libwxbase-dev and libwxgtk-dev?
I already know that a package is included in the other, but I need some more detailed information.
Thanks
IT
libwxbase-dev: wxBase library (development) - non-GUI support classes of wxWidgets toolkit
libwxgtk-dev: wxWidgets Cross-platform C++ GUI toolkit (GTK+ development)
The second is focused purely on the GUI, using the first.
The first contains basic functionalities of the wxWidgets toolkit, non-gui oriented.
Since Apple have stopped distributing gfortran with Xcode, how should I compile architecture independent Fortran code? I have Mac OS X Mountain Lion (10.8), and XCode 4.4 installed, with the Command Line Tools package installed.
Apple's Native Compilers
As far as I can tell, the Xcode C / C++ / ObjC compilers use a fork of the GNU compiler collection, with llvm as a backend; the latter I figure enables compiling and optimising "universal" binaries, for both Intel and PPC architectures.
3rd party binary Fortran compilers
HPC
I've only found a single website that distributes a binary version of gfortran specifically for Mountain Lion: the HPC website. However, I failed to get this to compile SciPy, and later saw in SciPy's README that it is "known to generate buggy scipy binaries".
CRAN/R
SciPy's recommended (free) Fortran compiler is the one on CRAN's R server, but this has not been updated for Mountain Lion yet. They provide instructions and a script for Building a Universal Compiler, but, again, this hasn't been updated for Mountain Lion yet..
G95
The G95 project hasn't had an update since 2010, so I didn't try it.. Anyone tried this on Mountain Lion?
MacPorts
I guess this will be the easiest way to get gfortran installed, but port search gfortran comes up with nothing, and I've not had any joy with MacPorts in the past (no offence to MacPorts; it's looks like a very active project, but I've been spoilt with Linux package managers, my favourite manager being aptitude) so on Mac OS X I've compiled software and libraries from source code in the past. Never been a problem 'til now...
Building a Fortran compiler
Having dug around on the internet a lot in the last couple of days, I've found other Fortran compilers, but I've failed to get any to cross-compile universal binaries, or to compile SciPy.
GCC - The Gnu Compiler Collection
I compiled the entire GCC collection (v4.6.3), including autotools, automake, libtool and m4 - like the GCC wiki and this blog describe - but the resulting compilers didn't compile universal binaries, probably because LLVM wasn't used as a backend.
DragonEgg
DragonEgg is a "gcc plugin that replaces GCC's optimisers and code-generators ... with LLVM". This looks interesting, but I don't know how I could use it to compile 'llvm-gfortran-4.x'. Can this be done?
Compatibility
Libraries
The compiler that comes with Xcode is (a fork of?) GCC v4.2. But GCC's current release and development branches are versions 4.6 and 4.7, respectively. Apparently, a GNU license change, or something, stopped Apple from updating to more modern versions of GCC. So, if I was to build dynamic libraries made with GCC's gfortran v4.6, could they then be linked with C code compiled by Xcode's native compiler? At a minimum, I figure resulting Mach-O binaries need both x86_64 and i386 code paths. Do GCC provide backwards compatibility with Apple's (forks of?) GCC? I know gfortran has the -ff2c flag, but is this stable across versions?
Compile flags
The GCC Fortran compiler I built from source didn't support the use of the -arch compile flag. I had been including the flags -arch x86_64 -arch i386 in both CFLAGS and FFLAGS environment variables on earlier OSX versions (Snow Leopard to Lion). Python's distutils, and probably other OSX compilers, expect these flags to work, when configured to build apps or frameworks, using Xcode's universal SDK.
In case you're wondering what compile flags I use, I've uploaded the script I use to pastebin, which I source before I compile anything, using: source ~/.bash_devenv.
The Ideal OSX Fortran Compiler
Create ppc and intel (32 and 64bit) universal binaries, specified by using the -arch flags.
Makes binaries compatible with XCode's linker.
Compiles SciPy, giving no errors (compatible with numpy's distutils and f2py).
I don't use Xcode so much, but integration with it would surely benefit other users. Even Intel are still having problems integrating ifort into Xcode 4.4, so this is not something I expect to work..
If you read all the above, then thank you! You can probably tell that I'm not averse to building my own Fortran compiler from source, but is it even possible? Have I missed something? A configure flag maybe? And if such a compiler is not available yet, then why not?!
(Update:) Apple's GCC
Apple provide the source code for their patched version of GCC, at opensource.apple.com. This actually includes the source code for gfortran, but what do you know - it doesn't compile (easily). I'm in the process of writing a build script to get this to work. Unfortunately, I've had to apply a couple of patches, and learn about "the Apple way" of building GNU software. This is the way to go I think. Any reasons why it shouldn't be? I'll update with an answer if I get it to work...
I managed to compile after installing gfortran from http://r.research.att.com/tools/gcc-42-5666.3-darwin11.pkg, as explained here. I had to try to open the package a couple of times, though. First time it said that only apps from App Store can be installed. After installing gfortran, python setup.py build and python setup.py install worked fine. The unit tests of scipy though give a fairly high number of fails, not sure it's normal.
Ran 5481 tests in 82.079s
FAILED (KNOWNFAIL=13, SKIP=42, errors=11, failures=72)
<nose.result.TextTestResult run=5481 errors=11 failures=72>
In case you didn't already notice this: In newer versions of Xcode you have to explicitly install command line tools in the following way:
Preferences -> Downloads -> Components
And then click the "install" button for command line tools. This includes gfortran:
> gfortran -v
Using built-in specs.
Target: i686-apple-darwin10
Thread model: posix
gcc version 4.2.1 (Apple Inc. build 5664)
Admittedly, this does not solve all of my fortran needs (in some cases "./configure" scripts will complain that they cannot "compile a simple fotran program").
You could use brew (or Homebrew) to install gfortran.
$ brew install gfortran
I know you said you don't like MacPorts, but if you install the gcc48 port, it does in fact include gfortran (although you'll also have to do sudo port select --set gcc mp-gcc48 to get it to set up the symlink named gfortran).
Also, FWIW, the MacPorts option is not necessarily a binary - MacPorts can actually build it from source, which is why it sometimes takes a while. On the other hand, it also sometimes seems to get archived binaries from somewhere, but I think it depends on what the original author of the portfile uploaded.
I ended up compiling gfortran the source code provided at Apple's developer tools source code page. This seems to be working okay now - I've successfully compiled x86-64 and i386/i686 LAPACK, ATLAS and BLAS fortran libraries - but there are some ranlib tests which fail, when running make -k test in the build directories. (I could provide more info on that pastebin or somewhere, if someone wants...)
Build process
After asking the question, I downloaded Apple's llvmgcc42 source code tar archive, which includes the source code for llvm/gcc C, C++, ObjC and fortran compilers, and spent some time trying to compile a universal build of gfortran. The build takes about 30-60 minutes on my quad-core 2.8GHz Mac Pro, and became quite an involved process, so I wrote a set of build scripts for it, which I've shared at github.com.
....
I'll keep a tar archive of my build here for the time being, if anyone would like a copy. (Updated 26-Sep-2012) It'll only work if installed with a prefix of /usr/local/ though, unless you run install_name_tool on the executables and dylibs, to change the prefix from /usr/local to wherever you want to put it. You can test install_name's with otool -L filename (more info on the reasons for this is here).
The final build I'm now using also includes updates to the gcc/fortran and libgfortran directories, which I got from GNU GCC 4.2.4. These sources I got from my local GCC's mirror. There were only minor changes between 4.2.1 and 4.2.4, and the build scripts include the patches needed to upgrade the code.
The build-gfortran.sh script I wrote downloads missing dependencies (mpfr and gmp), compiles and cross-compiles them, patches differing headers with architecture-dependent preprocessor macros, and runs lipo to create universal binaries and libraries, eventually supporting both i386 and x86_64 architectures. The process is similar for llvmCore, and then GCC. I mostly copied code from the build_llvm and build_gcc bash scripts provided with Apple's llvmgcc42, but had some of it had to be modified, including a few lipo and install_name_tool commands.
The official way to compile Apple's gcc, using Xcode's gnumake just didn't work for me. I thought this should work just byadding "fortran" to the LANGUAGES variable in build_gcc.
With regards to compiling Scipy, still can't get that building perfectly. I've had to use clang and clang++ as C/C++ compilers, or else I get EXC_BAD_ACCESS malloc errors. Haven't tried the gcc/g++ compilers I built, just used the system ones. This is as reported for Lion, on the Scipy install page. I'm down to 11 errors and 1 failure, which are all raised from the same 3 function calls (_fitpack._bspleval, numeric.asarray, testing.utils.chk_same_position). Think that's pretty good, but I'd like every test to pass...