This is the mail archive of the crossgcc@sourceware.org mailing list for the crossgcc project.

See the CrossGCC FAQ for lots more information.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Targetting Sparc/Solaris


Nathan Kidd wrote:
Sam Brightman wrote:
Since I was building from Solaris
2.11 (Nexenta A7) I initially tried to skip the library/header copy
stuff and mess around with the tree. This just led to trouble (PATH_MAX
stuff: not fixed by the patch in crosstools), so I've gone with pretty
much exactly as you wrote.

If you want your binary to run on Solaris 2.9 you can't link with a libc from e.g. 2.11. Newer libc symbols will get referenced in your app that won't resolve on an older libc.

I realised that this may be an issue, but is it a show-stopper? Since the whole idea is to cross-compile (i.e. could well be doing this from Linux/Cygwin), the 2.9 libraries won't be available natively. And Sun have said that they have no intention of open sourcing Solaris before version 10. That would suggest the only way to get the libraries may be to have the client send 200MB of files, probably not an option. Our app is quite simple by the way, only using C++ standard libraries, no threading.


If this is not possible, then further suggestions besides buying a 2.9 box are welcome... I'm still seeing the odd message or website that says Solaris/Linux ELF is generally a compatible format, and Solaris 9 started having Linux libraries (client has gcc and I think glibc). Wouldn't this make the original crosstools compiler feasible somehow?

I have
to leave for the day now, but wondering if the cause of this libc.so
link problem is immediately obvious to anyone?
...
Here is the tail of the build log:

/mnt/build/xgcc-4.1-build/sparc-sun-solaris2.9/gcc/./gcc/xgcc
-B/mnt/build/xgcc-4.1-build/sparc-sun-solaris2.9/gcc/./gcc/
-B/mnt/build/xgcc-4.1/sparc-sun-solaris2.9/sparc-sun-solaris2.9/bin/
-B/mnt/build/xgcc-4.1/sparc-sun-solaris2.9/sparc-sun-solaris2.9/lib/
...
-Wl,--soname=libgcc_s.so.1 -Wl,--version-script=libgcc/./libgcc.map -o
./libgcc_s.so.1.tmp  libgcc/./_muldi3_s.o libgcc/./_negdi2_s.o
...
/mnt/build/xgcc-4.1/sparc-sun-solaris2.9/bin/sparc-sun-solaris2.9-ld:
skipping incompatible /usr/lib/libc.so when searching for -lc
/mnt/build/xgcc-4.1/sparc-sun-solaris2.9/bin/sparc-sun-solaris2.9-ld:
cannot find -lc

Following the notes I had, you should have a solaris 2.9 libc under /mnt/build/xgcc-4.1/sparc-sun-solaris2.9/sparc-sun-solaris2.9/usr/lib/

E.g. on my system:

$ ls -l /xgcc-4.1/sparc-sun-solaris2.8/sparc-sun-solaris2.8/usr/lib/libc.*
-rw-r--r--  1 nathan staff 1788084 Dec  9  2002 libc.a
lrwxrwxrwx  1 nathan staff      11 Oct  5  2006 libc.so -> ./libc.so.1
-rwxr-xr-x  1 nathan staff 1157888 Dec  9  2002 libc.so.1

Questions to ask yourself:


1. Do you have the proper libc in that location?
2. Does your build try looking in that location? (e.g. use 'truss' to
find out what which libc.so files sparc-sun-solaris2.9-ld tries to open).

I had already made sure that it was in that location (well, 2.11 version), but had missed the fact that it's a broken symlink. It seems that on Nexenta libc.so amongst many others are in /lib. I'm trying the tar with the "-h" you warned against as we speak. Something obviously needs re-arranging there, I'll see if I can get it to work out.


--
sam brightman

--
For unsubscribe information see http://sourceware.org/lists.html#faq


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]