|
Ken MacKay
09/20/2007 4:39 PM
post1471
|
Suppose I want to port the toolchain to OS X (so I can compile on my OS X machine, then copy the binaries to my QNX
machine and run them). What steps should I take to do this?
Currently I have used the following steps (cobbled together from the build scripts):
1. On your OS X machine, create a directory for making the cross compiler in, eg mkdir -p /qnx/cross
2. Get a copy of the QNX target directory, ie /usr/qnx630/target/qnx6, from a QNX machine (latest version of Momentics
installed, and gcc 4.2.1 installed). Put the copy in /qnx/cross/target (so tar -cf qnx6.tar /usr/qnx630/target/qnx6; scp
qnx6.tar osx:/qnx6.tar; (on OS X) cd /qnx/cross; tar -xf /qnx6.tar; mv qnx6 target)
3. Set up directories:
mkdir -p /qnx/cross/host/usr
4. Set up environment variables:
export QNX_HOST=/qnx/cross/host
export QNX_TARGET=/qnx/cross/target
5. Get the QNX Core Development tools source, eg checked out to /qnx
6. Build binutils:
mkdir -p /qnx/cross/binutils-build
cd /qnx/cross/binutils-build
/qnx/core-dev-tools/tools/binutils/trunk/configure --with-sysroot=$QNX_TARGET --disable-werror --disable-shared --
disable-nls --prefix=$QNX_HOST/usr --exec-prefix=$QNX_HOST/usr --with-local-prefix=$QNX_HOST/usr --target=i386-pc-nto-
qnx6.3.0 --srcdir=/qnx/core-dev-tools/tools/binutils/trunk
make
make install
7. Build gcc:
mkdir -p /qnx/cross/gcc-build
cd /qnx/cross/gcc-build
export LDFLAGS="-Wl,-s"
/qnx/core-dev-tools/tools/gcc/trunk/configure --with-as=$QNX_HOST/usr/bin/i386-pc-nto-qnx6.3.0-as --with-ld=$QNX_HOST/
usr/bin/i386-pc-nto-qnx6.3.0-ld --enable-cheaders=c --with-sysroot=$QNX_TARGET/ --disable-werror --libdir=$QNX_HOST/usr/
lib --libexecdir=$QNX_HOST/usr/lib --target=i386-pc-nto-qnx6.3.0 --srcdir=/qnx/core-dev-tools/tools/gcc/trunk/ --prefix=
$QNX_HOST/usr/ --exec-prefix=$QNX_HOST/usr/ --with-local-prefix=$QNX_HOST/usr/ --enable-languages=c,c++ --enable-threads
=posix --disable-nls --disable-libssp --disable-tls --enable-__cxa_atexit --with-gxx-include-dir=$QNX_TARGET/usr/include
/c++/4.2.1 --disable-shared --disable-multilib
export CFLAGS="-Wall -O2"
make
make install
This works OK, except that there is some strange problem when initializing static variables (sometimes). I haven't
isolated the problem yet, but here is an example backtrace:
Program terminated with signal 11, Segmentation fault.
#0 0x00000000 in ?? ()
(gdb) bt
#0 0x00000000 in ?? ()
#1 0x0810416c in init ()
at /qnx/cross/gcc-build/i386-pc-nto-qnx6.3.0/libstdc++-v3/include/i386-pc-nto-qnx6.3.0/bits/gthr-default.h:644
#2 0x08110444 in __pthread_once ()
#3 0x081041d5 in get_static_mutex ()
at /qnx/cross/gcc-build/i386-pc-nto-qnx6.3.0/libstdc++-v3/include/i386-pc-nto-qnx6.3.0/bits/gthr-default.h:579
#4 0x0810433e in __cxa_guard_acquire (g=0x816bf78)
at /qnx/core-dev-tools/tools/gcc/trunk/libstdc++-v3/libsupc++/guard.cc:158
#5 0x0804f01c in boost::details::pool::singleton_default<boost::singleton_pool<Messaging::DataMessage, 64u, boost::
default_user_allocator_new_delete, boost::details::pool::pthread_mutex, 32u>::pool_type>::instance ()
at /qnx/cross/target//usr/include/boost/pool/detail/singleton.hpp:83
#6 0x0804f0bb in object_creator (this=0x816bfa0)
at /qnx/cross/target//usr/include/boost/pool/detail/singleton.hpp:66
#7 0x080b111f in __static_initialization_and_destruction_0 (__initialize_p=1,
__priority=65535)
at /qnx/cross/target//usr/include/boost/pool/detail/singleton.hpp:95
#8 0x080b115d in global constructors keyed to _ZNK9Messaging17DescriptorSetCompclERKSt3setIjSt4lessIjESaIjEES7_ () at
utilities.cpp:184
#9 0x0812b8c2 in __do_global_ctors_aux ()
#10 0x0804807e in _init ()
It seems as though some function didn't get linked in properly?
Anyway, I would like to port the toolchain to OS X properly (rather than the nonsense above), so if anybody could give
me some information about how to do that, I would be grateful.
-Ken
|
|
|
|
|
|
Thomas Fletcher
09/20/2007 5:08 PM
post1473
|
> -----Original Message-----
> From: Ken MacKay [mailto:kmackay@gmail.com]
> Sent: September 20, 2007 4:40 PM
> To: general-toolchain
> Subject: Porting to OS X
>
> Suppose I want to port the toolchain to OS X (so I can
> compile on my OS X machine, then copy the binaries to my QNX
> machine and run them). What steps should I take to do this?
There are a few barriers to accomplishing this, the most notable
is that the bootstrap environment is the binary distribution of
QNX Momentics. Now that in and of itself is not the end of the
world, but it makes things more awkward.
The key to the entire QNX build system is QNX_HOST pointing to
a set of host specific binaries and QNX_TARGET pointing to all
of the target binaries.
You will need to take everything under QNX_TARGET from a standard
distribution and bring it over to OS X (or make it available)
and then start working at populating your QNX_HOST environment.
The barrier you will run into rather quickly is that you don't
have a compiler front end (qcc) .. so if/when you get the gcc
compiler bootstrapped and up and running (it has been done) then
you will have to change the makefile targets (see
QNX_TARGET/usr/include/*.mk) to use gcc instead of qcc.
There is a not-insignificant amount of assumption in the makefiles
that qcc is being used to build.
Not impossible to overcome, but don't expect a clean compile
out of the box once the compiler is built =;-)
Thomas
> Currently I have used the following steps (cobbled together
> from the build scripts):
>
> 1. On your OS X machine, create a directory for making the
> cross compiler in, eg mkdir -p /qnx/cross
>
> 2. Get a copy of the QNX target directory, ie
> /usr/qnx630/target/qnx6, from a QNX machine (latest version
> of Momentics installed, and gcc 4.2.1 installed). Put the
> copy in /qnx/cross/target (so tar -cf qnx6.tar
> /usr/qnx630/target/qnx6; scp qnx6.tar osx:/qnx6.tar; (on OS
> X) cd /qnx/cross; tar -xf /qnx6.tar; mv qnx6 target)
>
> 3. Set up directories:
> mkdir -p /qnx/cross/host/usr
>
> 4. Set up environment variables:
> export QNX_HOST=/qnx/cross/host
> export QNX_TARGET=/qnx/cross/target
>
> 5. Get the QNX Core Development tools source, eg checked out to /qnx
>
> 6. Build binutils:
> mkdir -p /qnx/cross/binutils-build
> cd /qnx/cross/binutils-build
> /qnx/core-dev-tools/tools/binutils/trunk/configure
> --with-sysroot=$QNX_TARGET --disable-werror --disable-shared
> --disable-nls --prefix=$QNX_HOST/usr
> --exec-prefix=$QNX_HOST/usr --with-local-prefix=$QNX_HOST/usr
> --target=i386-pc-nto-qnx6.3.0
> --srcdir=/qnx/core-dev-tools/tools/binutils/trunk
> make
> make install
>
> 7. Build gcc:
> mkdir -p /qnx/cross/gcc-build
> cd /qnx/cross/gcc-build
> export LDFLAGS="-Wl,-s"
> /qnx/core-dev-tools/tools/gcc/trunk/configure
> --with-as=$QNX_HOST/usr/bin/i386-pc-nto-qnx6.3.0-as
> --with-ld=$QNX_HOST/usr/bin/i386-pc-nto-qnx6.3.0-ld
> --enable-cheaders=c --with-sysroot=$QNX_TARGET/
> --disable-werror --libdir=$QNX_HOST/usr/lib
> --libexecdir=$QNX_HOST/usr/lib --target=i386-pc-nto-qnx6.3.0
> --srcdir=/qnx/core-dev-tools/tools/gcc/trunk/
> --prefix=$QNX_HOST/usr/ --exec-prefix=$QNX_HOST/usr/
> --with-local-prefix=$QNX_HOST/usr/ --enable-languages=c,c++
> --enable-threads=posix --disable-nls --disable-libssp
> --disable-tls --enable-__cxa_atexit
> --with-gxx-include-dir=$QNX_TARGET/usr/include/c++/4.2.1
> --disable-shared --disable-multilib export CFLAGS="-Wall -O2"
> make
> make install
>
> This works OK, except that there is some strange problem when
> initializing static variables (sometimes). I haven't isolated
> the problem yet, but here is an example backtrace:
>
> Program...
View Full Message
|
|
|
|
|
|
Ken MacKay
09/20/2007 5:33 PM
post1474
|
I guess that is essentially what I did, although I didn't alter the make system (I just ran the commands directly). I
have a 'working' cross compiler now from OS X -> QNX on x86; there is just the problem where some of the compiled
programs crash on startup (eg, the backtrace from my first post is from one of these programs - compiled on OS X, and
when run on a QNX machine, it segfaults on startup).
I can try changing the make system so that it will work directly, I'll see if that helps.
|
|
|
|
|
|
Thomas Fletcher
09/21/2007 8:10 AM
post1484
|
> -----Original Message-----
> From: Ken MacKay [mailto:kmackay@gmail.com]
> Sent: September 20, 2007 5:34 PM
> To: general-toolchain
> Subject: Re: RE: Porting to OS X
>
> I guess that is essentially what I did, although I didn't
> alter the make system (I just ran the commands directly). I
> have a 'working' cross compiler now from OS X -> QNX on x86;
> there is just the problem where some of the compiled programs
> crash on startup (eg, the backtrace from my first post is
> from one of these programs - compiled on OS X, and when run
> on a QNX machine, it segfaults on startup).
>
> I can try changing the make system so that it will work
> directly, I'll see if that helps.
Well if you have a working cross compiler, then that is the
next thing to do ... might as well go all the way* on this one =;-)
The makefile bits all live in
$QNX_TARGET/usr/include/*.mk
and
$QNX_TARGET/usr/include/mk/*
The one that is interesting for configuring a particular host
to build is $QNX_TARGET/usr/include/qconfig.mk. This file
holds all of the definitions for build commands that are to
be used on that host.
As you can see in the $QNX_TARGET/usr/include/mk/* directory
there are other sample host qconfig files (qconf-nto.mk for
Neutrino, qconf-qnx4 for QNX4, qconf-win32 for Windows).
If you use these as a template, you can create a qconfig.mk
for osx and map the compiler to gcc instead of qcc.
Hope this helps,
Thomas
* All the way without qcc that is =;-)
|
|
|
|
|
|
Colin Burgess(deleted)
09/21/2007 10:08 AM
post1485
|
You should count yourself lucky that you at least have a native compiler
to start with! :-)
Many years ago someone hacked up qnx to run on a PPC mac, and I made a
ppc hosted compiler for it. Now doing a canadian
cross is NOT a particularly fun process.... :-)
Thomas Fletcher wrote:
>
>
>
> > -----Original Message-----
> > From: Ken MacKay [mailto:kmackay@gmail.com]
> > Sent: September 20, 2007 5:34 PM
> > To: general-toolchain
> > Subject: Re: RE: Porting to OS X
> >
> > I guess that is essentially what I did, although I didn't
> > alter the make system (I just ran the commands directly). I
> > have a 'working' cross compiler now from OS X -> QNX on x86;
> > there is just the problem where some of the compiled programs
> > crash on startup (eg, the backtrace from my first post is
> > from one of these programs - compiled on OS X, and when run
> > on a QNX machine, it segfaults on startup).
> >
> > I can try changing the make system so that it will work
> > directly, I'll see if that helps.
>
> Well if you have a working cross compiler, then that is the
> next thing to do ... might as well go all the way* on this one =;-)
>
> The makefile bits all live in
> $QNX_TARGET/usr/include/*.mk
> and
> $QNX_TARGET/usr/include/mk/*
>
> The one that is interesting for configuring a particular host
> to build is $QNX_TARGET/usr/include/qconfig.mk. This file
> holds all of the definitions for build commands that are to
> be used on that host.
>
> As you can see in the $QNX_TARGET/usr/include/mk/* directory
> there are other sample host qconfig files (qconf-nto.mk for
> Neutrino, qconf-qnx4 for QNX4, qconf-win32 for Windows).
>
> If you use these as a template, you can create a qconfig.mk
> for osx and map the compiler to gcc instead of qcc.
>
> Hope this helps,
> Thomas
>
>
> * All the way without qcc that is =;-)
>
> _______________________________________________
> General
> http://community.qnx.com/sf/go/post1484
>
--
cburgess@qnx.com
|
|
|
|
|
|
Ryan Mansfield(deleted)
09/21/2007 10:14 AM
post1486
|
> You should count yourself lucky that you at least have a native compiler
> to start with! :-)
>
> Many years ago someone hacked up qnx to run on a PPC mac, and I made a
> ppc hosted compiler for it. Now doing a canadian
> cross is NOT a particularly fun process.... :-)
Maybe it was more painful in the past but the GCC 4.2.1 and Binutils 2.17 packages (two of three) were Canadian crossed
from one host. It has speeding up and actually simplified our build of the toolchains.
Regards,
Ryan Mansfield
|
|
|
|
|
|
Colin Burgess(deleted)
09/21/2007 10:17 AM
post1487
|
Yeah, this was a 2.95.3 port. I'm glad to hear it's easier these days.
So you build a 4.21 that is hosted on windows, but targets qnx, under qnx?
Ryan Mansfield wrote:
>
> > You should count yourself lucky that you at least have a native
> compiler
> > to start with! :-)
> >
> > Many years ago someone hacked up qnx to run on a PPC mac, and I made a
> > ppc hosted compiler for it. Now doing a canadian
> > cross is NOT a particularly fun process.... :-)
>
> Maybe it was more painful in the past but the GCC 4.2.1 and Binutils
> 2.17 packages (two of three) were Canadian crossed from one host. It
> has speeding up and actually simplified our build of the toolchains.
>
> Regards,
>
> Ryan Mansfield
>
> _______________________________________________
> General
> http://community.qnx.com/sf/go/post1486
>
--
cburgess@qnx.com
|
|
|
|
|
|
Ryan Mansfield(deleted)
09/21/2007 10:22 AM
post1488
|
> Yeah, this was a 2.95.3 port. I'm glad to hear it's easier these days.
>
> So you build a 4.21 that is hosted on windows, but targets qnx, under qnx?
Yep. Cool eh?
Regards,
Ryan Mansfield
> Ryan Mansfield wrote:
> >
> > > You should count yourself lucky that you at least have a native
> > compiler
> > > to start with! :-)
> > >
> > > Many years ago someone hacked up qnx to run on a PPC mac, and I made a
> > > ppc hosted compiler for it. Now doing a canadian
> > > cross is NOT a particularly fun process.... :-)
> >
> > Maybe it was more painful in the past but the GCC 4.2.1 and Binutils
> > 2.17 packages (two of three) were Canadian crossed from one host. It
> > has speeding up and actually simplified our build of the toolchains.
> >
> > Regards,
> >
> > Ryan Mansfield
> >
> > _______________________________________________
> > General
> > http://community.qnx.com/sf/go/post1486
> >
>
> --
> cburgess@qnx.com
>
|
|
|
|
|
|
Colin Burgess(deleted)
09/21/2007 10:24 AM
post1489
|
Indeed!
Ryan Mansfield wrote:
>
> > Yeah, this was a 2.95.3 port. I'm glad to hear it's easier these days.
> >
> > So you build a 4.21 that is hosted on windows, but targets qnx,
> under qnx?
>
> Yep. Cool eh?
>
> Regards,
>
> Ryan Mansfield
>
> > Ryan Mansfield wrote:
> > >
> > > > You should count yourself lucky that you at least have a native
> > > compiler
> > > > to start with! :-)
> > > >
> > > > Many years ago someone hacked up qnx to run on a PPC mac, and I
> made a
> > > > ppc hosted compiler for it. Now doing a canadian
> > > > cross is NOT a particularly fun process.... :-)
> > >
> > > Maybe it was more painful in the past but the GCC 4.2.1 and Binutils
> > > 2.17 packages (two of three) were Canadian crossed from one host. It
> > > has speeding up and actually simplified our build of the toolchains.
> > >
> > > Regards,
> > >
> > > Ryan Mansfield
> > >
> > > _______________________________________________
> > > General
> > > http://community.qnx.com/sf/go/post1486
> > >
> >
> > --
> > cburgess@qnx.com
> >
>
>
>
>
> _______________________________________________
> General
> http://community.qnx.com/sf/go/post1488
>
--
cburgess@qnx.com
|
|
|
|
|
|
Colin Burgess(deleted)
09/21/2007 10:31 AM
post1490
|
BTW - http://en.wikipedia.org/wiki/Cross_compiler#Canadian_Cross
"The term *Canadian Cross* came about because at the time that these
issues were all being hashed out, Canada had three national political
parties."
I had always thought it was because the crazy canadian guys at Cygnus
(in Toronto, later bought by Redhat) were the only guys crazy enough to
try such a build system.
LOL
Colin
Ryan Mansfield wrote:
>
> > Yeah, this was a 2.95.3 port. I'm glad to hear it's easier these days.
> >
> > So you build a 4.21 that is hosted on windows, but targets qnx,
> under qnx?
>
> Yep. Cool eh?
>
> Regards,
>
> Ryan Mansfield
>
> > Ryan Mansfield wrote:
> > >
> > > > You should count yourself lucky that you at least have a native
> > > compiler
> > > > to start with! :-)
> > > >
> > > > Many years ago someone hacked up qnx to run on a PPC mac, and I
> made a
> > > > ppc hosted compiler for it. Now doing a canadian
> > > > cross is NOT a particularly fun process.... :-)
> > >
> > > Maybe it was more painful in the past but the GCC 4.2.1 and Binutils
> > > 2.17 packages (two of three) were Canadian crossed from one host. It
> > > has speeding up and actually simplified our build of the toolchains.
> > >
> > > Regards,
> > >
> > > Ryan Mansfield
> > >
> > > _______________________________________________
> > > General
> > > http://community.qnx.com/sf/go/post1486
> > >
> >
> > --
> > cburgess@qnx.com
> >
>
>
>
>
> _______________________________________________
> General
> http://community.qnx.com/sf/go/post1488
>
--
cburgess@qnx.com
|
|
|
|
|
|
Ryan Mansfield(deleted)
09/20/2007 6:40 PM
post1475
|
> 7. Build gcc:
> mkdir -p /qnx/cross/gcc-build
> cd /qnx/cross/gcc-build
> export LDFLAGS="-Wl,-s"
> /qnx/core-dev-tools/tools/gcc/trunk/configure --with-as=$QNX_HOST/usr/bin/
> i386-pc-nto-qnx6.3.0-as --with-ld=$QNX_HOST/usr/bin/i386-pc-nto-qnx6.3.0-ld --
> enable-cheaders=c --with-sysroot=$QNX_TARGET/ --disable-werror --libdir=$
> QNX_HOST/usr/lib --libexecdir=$QNX_HOST/usr/lib --target=i386-pc-nto-qnx6.3.0
> --srcdir=/qnx/core-dev-tools/tools/gcc/trunk/ --prefix=$QNX_HOST/usr/ --exec-
> prefix=$QNX_HOST/usr/ --with-local-prefix=$QNX_HOST/usr/ --enable-languages=c,
> c++ --enable-threads=posix --disable-nls --disable-libssp --disable-tls --
> enable-__cxa_atexit --with-gxx-include-dir=$QNX_TARGET/usr/include/c++/4.2.1 -
> -disable-shared --disable-multilib
> export CFLAGS="-Wall -O2"
> make
> make install
Hi Ken,
You'll probably want to build with --enable-shared and --enable-multilib. The --disable-shared and --disable-multilib
were added to our build-hooks file to speed up our build by only building the target libs for one host and then copying
them over to others.
Does the same program crash if compiled with the packaged gcc 4.2.1?
Regards,
Ryan Mansfield
|
|
|
|
|
|
Ken MacKay
09/20/2007 7:15 PM
post1477
|
> You'll probably want to build with --enable-shared and --enable-multilib. The
> --disable-shared and --disable-multilib were added to our build-hooks file to
> speed up our build by only building the target libs for one host and then
> copying them over to others.
OK, I'll try that and see if that helps.
> Does the same program crash if compiled with the packaged gcc 4.2.1?
It doesn't crash if I compile it with the packaged gcc 4.2.1 on the QNX system.
-Ken
|
|
|
|
|
|
Ken MacKay
09/24/2007 3:14 PM
post1548
|
So I stepped though the program with the debugger, and just before the crash occurs, it goes through the following
assembly code:
Dump of assembler code for function _ZN96_GLOBAL__N__qnx_core_dev_tools_tools_gcc_trunk_libstdc___v3_libsupc___guard.
cc_00000000_875FCF4E4initEv:
0x08104140 <init+0>: push %ebp
0x08104141 <init+1>: mov %esp,%ebp
0x08104143 <init+3>: push %ebx
0x08104144 <init+4>: sub $0x24,%esp
0x08104147 <init+7>: mov $0x810fef8,%eax
0x0810414c <init+12>: test %eax,%eax
0x0810414e <init+14>: jne 0x8104160 <init+32>
0x08104150 <init+16>: movl $0x8174e74,0x8174e7c
0x0810415a <init+26>: mov 0xfffffffc(%ebp),%ebx
0x0810415d <init+29>: leave
0x0810415e <init+30>: ret
0x0810415f <init+31>: nop
0x08104160 <init+32>: sub $0xc,%esp
0x08104163 <init+35>: lea 0xffffffdc(%ebp),%ebx
0x08104166 <init+38>: push %ebx
0x08104167 <init+39>: call 0x0
0x0810416c <init+44>: add $0x10,%esp
0x0810416f <init+47>: test %eax,%eax
0x08104171 <init+49>: jne 0x8104150 <init+16>
0x08104173 <init+51>: sub $0x8,%esp
...
You can see that the compiler is generating call 0x00, which is clearly wrong. The relevant code is from gthr-default.h:
<line 634>
#ifndef PTHREAD_RECURSIVE_MUTEX_INITIALIZER_NP
static inline int
__gthread_recursive_mutex_init_function (__gthread_recursive_mutex_t *mutex)
{
if (__gthread_active_p ())
{
pthread_mutexattr_t attr;
int r;
r = __gthrw_(pthread_mutexattr_init) (&attr); <line 644> => compiler generates 'call 0x00' from this line
if (!r)
r = __gthrw_(pthread_mutexattr_settype) (&attr, PTHREAD_MUTEX_RECURSIVE);
if (!r)
r = __gthrw_(pthread_mutex_init) (mutex, &attr);
if (!r)
r = __gthrw_(pthread_mutexattr_destroy) (&attr);
return r;
}
return 0;
}
#endif
It seems like the compiler can't figure out where the code for that function is, so it just calls NULL instead. I'm not
sure why it doesn't stop compilation with an error though. I tried compiling with -fno-weak, but it made no difference.
-Ken
Any ideas?
|
|
|
|
|
|
Ryan Mansfield(deleted)
09/24/2007 4:08 PM
post1551
|
> It seems like the compiler can't figure out where the code for that function
> is, so it just calls NULL instead. I'm not sure why it doesn't stop
> compilation with an error though. I tried compiling with -fno-weak, but it
> made no difference.
>
> -Ken
>
> Any ideas?
How are you linking your program? My guess would be that the linker
finds a weak undefined symbol and doesn't keep searching libs for the
real one. The System V Application Binary Interface says:
"When the link editor searches archive libraries, it extracts
archive members that contain definitions of undefined global
symbols. The member's definition may be either a global or a weak
symbol. The link editor does not extract archive members to resolve
undefined weak symbols. Unresolved weak symbols have a
zero value. "
Regards,
Ryan Mansfield
|
|
|
|
|
|
Ken MacKay
09/24/2007 4:35 PM
post1552
|
> How are you linking your program? My guess would be that the linker
> finds a weak undefined symbol and doesn't keep searching libs for the
> real one.
Right now I am just linking using g++. For example:
/qnx/cross/host/usr/i386-pc-nto-qnx6.3.0/bin/g++ -static -o x86/select x86/select.o -L/trunk/Includes/Network/C++/x86 -
Wl,-rpath,/trunk/Includes/Network/C++/x86 -lIncludes_Network_C++ -lsocket
where libIncludes_Network_C++.a is created using ar:
/qnx/cross/host/usr/i386-pc-nto-qnx6.3.0/bin/ar rf x86/libIncludes_Network_C++.a x86/ClientSocket.o x86/ServerSocket.o
x86/UdpMulticastReceiver.o x86/UdpMulticastSender.o
|
|
|
|
|
|
Ken MacKay
|
Porting to OS X - solved linking problem
|
|
Ken MacKay
09/28/2007 7:37 PM
post1703
|
Porting to OS X - solved linking problem
I used the output from qcc to generate a link command for the OS X -> QNX cross compiler:
$QNX_HOST/usr/bin/i386-pc-nto-qnx6.3.0-ld -b elf32-i386 -m i386nto --dynamic-linker /usr/lib/ldqnx.so.2 -rpath-link /usr
/qnx630/target/qnx6/x86/lib:/usr/qnx630/target/qnx6/x86/usr/lib:/usr/qnx630/target/qnx6/x86/lib/gcc/4.2.1:/usr/qnx630/
target/qnx6/x86/opt/lib $QNX_TARGET/x86/lib/crt1.o $QNX_TARGET/x86/lib/crti.o $QNX_HOST/usr/lib/gcc/i386-pc-nto-qnx6.3.0
/4.2.1/crtbegin.o x86/select.o -L/trunk/Includes/Network/C++/x86 -rpath /trunk/Includes/Network/C++/x86 -
lIncludes_Network_C++ -lsocket -lDIOS_Includes_Network_C++ -lsocket -o x86/select -Y$QNX_TARGET/x86/lib:$QNX_TARGET/x86/
usr/lib:$QNX_TARGET/x86/opt/lib -L$QNX_HOST/usr/lib/gcc/i386-pc-nto-qnx6.3.0/4.2.1/ -L$QNX_TARGET/x86/lib/gcc/4.2.1 -L$
QNX_TARGET/usr/i386-pc-nto-qnx6.3.0/lib/ -L$QNX_TARGET/usr/lib -L$QNX_TARGET/x86/lib/ -L$QNX_TARGET/x86/lib -L$
QNX_TARGET/x86/usr/lib -L$QNX_TARGET/x86/opt/lib -lcpp -lcxa -lcpp $QNX_HOST/usr/lib/gcc/i386-pc-nto-qnx6.3.0/4.2.1//
libgcc.a -lc -dn -Bstatic -lc $QNX_HOST/usr/lib/gcc/i386-pc-nto-qnx6.3.0/4.2.1//libgcc.a $QNX_HOST/usr/lib/gcc/i386-pc-
nto-qnx6.3.0/4.2.1/crtend.o $QNX_TARGET/x86/lib/crtn.o
And everything seems to work nicely; so far, all the applications I have tried have run without any problems. I'm no
compiler / linker expert, but my guess is that when libcpp and libc are loaded dynamically, the missing thread-related
functions are loaded.
I made some scripts to add all the extra stuff to the link command above, but if I had a ported version of qcc, it would
probably work better (since qcc is usually the one that adds all of the crt stuff and the rest). I thought someone
mentioned that qcc might be released in the future; is there any further word on that?
-Ken
|
|
|
|
|
|
Wade Hawkins(deleted)
|
Re: Porting to OS X - solved linking problem
|
|
Wade Hawkins(deleted)
10/01/2007 10:47 AM
post1725
|
Re: Porting to OS X - solved linking problem
Currently there is no planned date for the release of qcc. We are still looking into the matter. We will give you an
update once plans have been finalized.
|
|
|
|
|
|
Ryan Mansfield(deleted)
|
Re: Porting to OS X - solved linking problem
|
|
Ryan Mansfield(deleted)
10/02/2007 10:03 AM
post1756
|
Re: Porting to OS X - solved linking problem
One of our Multimedia developers, Dan Cardamore (http://mediatype.ca/) uses OS X as his host and has provided a Mach-o
executable of qcc.
Regards,
Ryan Mansfield
|
|
|
|
|
|
