I'd like to build 32-bit Poco libraries on Mac OS (since I have other fixed 32-bit dependencies). By default, Poco only builds for the x86_64 target, however.
I tried building Poco like this (according to the Poco build instructions):
POCO_TARGET_OSARCH=i386 make
However, it still only builds for x86_64. Any ideas?
============================================
Well, it turns out the answer is this (in case anyone else runs into this):
You need to export these two variables before running configure and make:
POCO_TARGET_OSARCH="i386"
ARCHFLAGS="-arch i386"
Poco now has a configuration to build 32-bit directly on Mac OS X. Specify --config=Darwin32
when running ./configure
You can try this :
gedit poco-1.4.1p1-all/build/config/Darwin
change these flags to your desired architecture ARCHFLAGS,
POCO_TARGET_OSARCH
NOTE ./configure then only "make".
Related
this question has been asked before, but none of the answers seem to be currently working.. whether that's because they are incomplete, or things have changed, I don't know.
I build my code for a deployment target of 10.7 (my clients use their machines for music production, so they often prefer to stick with what they know works rather than updated with every new OS release).
I'm using boost.
So when I buid I get a bunch of warnings
ld: warning: object file (/usr/local/lib/libboost_filesystem.a(path.o)) was built for newer OSX version (10.10) than being linked (10.7)
ld: warning: object file (/usr/local/lib/libboost_system.a(error_code.o)) was built for newer OSX version (10.10) than being linked (10.7)
and so on.
So, I want to build boost (version 1.58 currently, unfortunately cmake is usually a couple of versions behind in what it can find) for a deployment target of 10.7
It seems the magic instruction is
macosx-version-min=10.7
except I can't make it work.
./bootstrap.sh
sudo ./b2 -a macosx-version-min=10.7 install
Just doesn't do it, nor do any of the other things I've tried (I'm not familar with how b2 works, so I'm grasping in the dark).
I expect I'm missing something simple, but some help would be much appreciated
regards
Jon
I ran into the same issue and could only fix it by building boost with the 10.7 library. I've used XCode 8.2.1. Here is what I did:
Modifying "Darwin.Jam". Look for this line: feature macosx-version-min : : propagated optional ;
and add this line below feature.extend macosx-version-min : 10.7 ;
Modify "Info.plist" in /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform and set <key>MinimumSDKVersion</key>
<string>10.11</string>
Make sure your XCode.app has the 10.7 SDK installed. This is the right location: /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs You can extract or copy it from an earlier version of XCode.
Now build boost with these options: cxxflags="-stdlib=libc++ -std=c++11 -mmacosx-version-min=10.7 -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.7.sdk"
E.g. ./b2 -a cxxflags="-stdlib=libc++ -std=c++11 -mmacosx-version-min=10.7 -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.7.sdk"
The solution above will build Boost with the 10.7 SDK instead just setting the Target SDK to 10.7
I have a project written in gcc - bison -flex on Linux environment. All the project is implemented into a *.so file and is called from python-tkinter graphic surface.
There is a need to run it on windows. However I'd avoid to install all the windows equivalent of gcc - bison -flex programs.
Is it possible to force gcc IN LINUX ENVIRONMENT to compile WINDOWS DLL instead of *.so? It could make life easier to use the same technics as I do now: just do calls from python-tkinter graphic surface.
You can, of course, cross-compile it.
You'll need some packages installed, though.
Your normal project would be able to build if you use the MINGW equivalent of GCC for the target architecture.
Also, take a look at this:
Manual for cross-compiling a C++ application from Linux to Windows?
The linking can be kind of troublesome though, since it could come a time where softlinking fails due to versions. In that case you'll need to create some symbolic links to the correct version.
The output of the compilation process should be with -o DYNAMIC-LIBRARIE-NAME.dll and of course use the -shared flag.
Hope it gives you some pointers..
Regards.
I want to compile a source code, but there are some compiling errors about __sync_xxx functions (__sync_bool_compare_and_swap etc.)
GCC version on machine is 3.4.3 (it must be gcc 4.1 or over for supporting atomic builtins), so I have downloaded GCC v4.6, copied it to another directory (I didn't remove v3.4.3) then change the $PATH path for GCC but it doesn't work (the same error occurs).
I want to ask that is only changing gcc path with export PATH=... enough for compiling with new GCC?
Use the following configure option when compiling gcc:
--program-prefix=foo --program-suffix=bar
and it will produce bin programs of the form "foo-gcc-bar", so that you may differentiate different builds of gcc.
Replace foo and/or bar with an appropriate "tag" for your build (eg "-4.6" for example).
This way if it doesn't find your toolchain correctly it will fail fast rather than using the 3.4 version.
It also means that different toolchain builds can coexist in the standard installation prefix directories.
We have to use -march=686 switch to get it to work on intel.
Try checking and updating LD_LIBRARY_PATH, to use the lib path for the new gcc installed.
The way I understand gcc, /usr/bin/gcc (and other bits related to gcc, like ld) is a small wrapper that delegates to a platform-specific binary somewhere else on the system.
So does compilation still work correctly if you have a cross compiler that is a couple of versions behind /usr/bin/gcc?
Yes, the whole Idea is to allow gcc to be installed in different versions and for different target platforms (in any combination) to be installed in parallel.
/usr/bin/gcc just uses fork+exec to call the actual compiler. The command line arguments given to gcc are just passed to the actual compiler with two exceptions: -V and -b. The latter selects the target platform the former the version of the compiler.
You won't use /usr/bin/gcc to cross-compile. Instead you'll install another compiler in another prefix. For instance if you're on debian/ubuntu you can install a ming (win32) cross-compiler by doing:
apt-get install mingw32
Which will work perfectly fine side by side with the normal gcc.
I am trying to build a cross-compiler with x86_64 being the host and i386 being the target. I'm getting the (all to common) crti.o: No such file error. Instead of grabbing an already built crti.o and crtn.o from a distro... how might I go about building these files explicitly from glibc (or possibly gcc) sources?
FYI, I am well aware of the -m32 option for x86_64 compilers. I'd prefer to just have a 32bit-only compiler environment. Also, the reason I don't want to use any of the gazillion already build i386 compilers is because I plan on mixing and matching glibc/binutils/gcc versions depending on my testing needs.
Thanks,
Chenz
Here's one possibility (from here)
You need to install your distro's 32
bit libc-dev package, or you need to
--disable-multilib which will result in a compiler that doesn't support 32
bit mode.
Are you sure you're using configuring the cross-compile correctly? It should be
CBUILD = CHOST = x86_64-pc-linux-gnu
CTARGET = i386-pc-linux-gnu
as you're running a build on an x86_64, for a compiler to run on an x86_64, which generates code for an i386.
If you used CHOST = i386-pc-linux-gnu, you'll be trying to generate 32-bit binaries, which will need to link with a 32-bit libc. Which is fine, if you already have a 32-bit libc, but it sounds like you don't.
i.e.
$ tar xvjf gcc-*.tar.bz2
$ cd gcc-*/
$ mkdir build
$ cd build
$ ../configure --build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu --target=i386-pc-linux-gnu