| All Forums |
Register |
Login |
Search |
Subscriptions |
My Profile |
Inbox |
| Tool Warehouse |
FAQs |
Resources |
Help |
Member List |
Address Book |
Logout |
|
|
cross compiling from Interix 5.2 to 3.5
|
Logged in as: Guest |
| Users viewing this topic: none |
|
Login  |
|
|
 cross compiling from Interix 5.2 to 3.5 - Mar. 6, '06, 8:58:24 PM
|
|
|
breiter
Posts: 343
Joined: Jun. 14, '04,
From: Washington, DC
Status: offline
|
How do I build SFU/Interix 3.5 binaries with gcc from SUA/Interix 5.2?
|
|
|
|
 RE: cross compiling from Interix 5.2 to 3.5 - Mar. 13, '06, 11:29:17 AM
|
|
|
jerker_back
Posts: 68
Joined: Jul. 7, '05,
From: Sweden
Status: offline
|
According to MS, SFU 3.5 binaries should run in SUA. I've tested this and had NO problem. You can NOT have both the SUA and SFU environment installed side by side.
To compile and link -easy- use Visual Studio and point your dependencies to SFU 3.5 headers and libs. It's perfectly OK just to copy them from installation folders. Just disable the security checks (/GS-) since SFU don't have them. Using cc or gcc from SUA? Scary, but might work.
The hard part is to be able to test and debug your builds in a working SFU environment. XP with SFU 3.5 in a virtual machine? Remote debug???
regards Jerker
|
|
|
|
|
RE: cross compiling from Interix 5.2 to 3.5 - Mar. 13, '06, 11:54:57 AM
|
|
|
jerker_back
Posts: 68
Joined: Jul. 7, '05,
From: Sweden
Status: offline
|
Sorry, I've read your question again - understand the problem.
I think, the gcc implementation is the same in SUA and SFU. Anyway, even if they are not it doesn't matter. The important part is what's in '/usr/include' and '/usr/lib' - right? Why not rename these to:
/usr/inc_SUA, /usr/lib_SUA etc
and do a
ln -s /usr/inc_SFU /usr/include
ln -s /usr/lib_SFU /usr/lib
you can then shift between the environments with a simple ln command
regards Jerker
|
|
|
|
|
RE: cross compiling from Interix 5.2 to 3.5 - Mar. 13, '06, 5:18:31 PM
|
|
|
breiter
Posts: 343
Joined: Jun. 14, '04,
From: Washington, DC
Status: offline
|
Well, actually, the issue is that when you build stuff in SUA it links against the 5.2 shared libraries. For example, here's xgalaga built for SUA:
% objdump -p xgalaga | egrep -i needed
NEEDED libX11.so.5.2
NEEDED libXext.so.5.2
NEEDED libXpm.so
NEEDED libc.so.5.2
Since libc.so.5.2, libX11.so.5.2 and libXext.so.5.2 don't exist on Interix 3.5 I'm assuming this binary won't run. However the *.so.3.5 libraries exist on SUA/Interix 5.2. What's the incantation to get a binary linked against the 3.5 shared libs when building on 5.2?
|
|
|
|
|
RE: cross compiling from Interix 5.2 to 3.5 - Mar. 13, '06, 9:44:19 PM
|
|
|
Rodney
Posts: 3695
Joined: Jul. 9, '02,
From: /Tools lab
Status: online
|
From what I've heard there are a couple of minor differences between gcc on 3.5 and 5.2.
The 5.2 version is supposed to have the DEP problem fixed. Note that this does NOT fix the 3.5
DEP situation unless you static build with all libraries being 5.2 built.
Try setting "-L" to the location of the 3.5 libs and adding "-rpath" to the link to ensure a runtime of 3.5.
|
|
|
|
|
RE: cross compiling from Interix 5.2 to 3.5 - Mar. 15, '06, 10:35:32 AM
|
|
|
breiter
Posts: 343
Joined: Jun. 14, '04,
From: Washington, DC
Status: offline
|
quote:
Try setting "-L" to the location of the 3.5 libs and adding "-rpath" to the link to ensure a runtime of 3.5.
-L doesn't help because the *.so.3.5 and *.so.5.2 libraries are in the same directory. -rpath doesn't help for the same reason.
|
|
|
|
|
RE: cross compiling from Interix 5.2 to 3.5 - Mar. 15, '06, 11:18:23 AM
|
|
|
breiter
Posts: 343
Joined: Jun. 14, '04,
From: Washington, DC
Status: offline
|
It looks like libc.so.5.2 is hard-coded into gcc.
% strings gcc | egrep 5.2
libc.so.5.2
Maybe the thing to do is to use the Interix 3.5 version of gcc?
|
|
|
|
|
RE: cross compiling from Interix 5.2 to 3.5 - Mar. 15, '06, 1:47:08 PM
|
|
|
Rodney
Posts: 3695
Joined: Jul. 9, '02,
From: /Tools lab
Status: online
|
> Maybe the thing to do is to use the Interix 3.5 version of gcc?
I don't know for sure... though the DEP thing still exists with it.
Another option may be to try the gcc 4.X tarball.
|
|
|
|
|
RE: cross compiling from Interix 5.2 to 3.5 - Mar. 29, '06, 8:11:11 AM
|
|
|
breiter
Posts: 343
Joined: Jun. 14, '04,
From: Washington, DC
Status: offline
|
I tried using the -Wl,-soname,lib gcc compiler flag, which seems like it should be the way to get gcc to tell ld to link against .so.3.5 libraries.
However, it doesn't work. I get an error that ld can't find the library, even though they are all in my LD_LIBRARY_PATH. It seems like I'm close to a solution. Any help?
gcc -L/usr/local/lib -L/usr/local/ssl/lib -Wl,-soname,libc.so.3.5 -Wl,-soname,li
bSM.so.3.5 -Wl,-soname,libICE.so.3.5 -Wl,-soname,libXext.so.3.5 -Wl,-soname,libX
11.so.3.5 -o aterm command.o graphics.o grkelot.o main.o menubar.o misc.o netdi
sp.o rmemset.o screen.o scrollbar.o utmp.o xdefaults.o pixmap.o thai.o -L/
usr/X11R6/lib -lSM -lICE -lX11 -lXext
/opt/gcc.3.3/lib/gcc-lib/i586-pc-interix3/3.3/../../../../i586-pc-interix3/bin/l
d: cannot open libc.so.3.5: No such file or directory
collect2: ld returned 1 exit status
*** Error code 1
|
|
|
|
|
RE: cross compiling from Interix 5.2 to 3.5 - Mar. 29, '06, 9:03:26 AM
|
|
|
Rodney
Posts: 3695
Joined: Jul. 9, '02,
From: /Tools lab
Status: online
|
How about using "-rpath" to specify the library location?
Then take a look at the o/p from "objdump -p" to see what's there.
|
|
|
|
|
RE: cross compiling from Interix 5.2 to 3.5 - Mar. 29, '06, 10:37:04 AM
|
|
|
breiter
Posts: 343
Joined: Jun. 14, '04,
From: Washington, DC
Status: offline
|
I tried -rpath, but it doesn't work. Also the -rpath documentation in ld(1) indicates that -rpath-link should be used for shared libraries.
quote:
-rpath-link directory
When using ELF or SunOS, one shared library might require another.
This happens when an ld -shared(1) link includes a shared library as
one of the input files.
If the linker encounters such a dependency when doing a non-shared,
non-relocateable link, it will automatically try to locate the
required shared library and include it in the link, if it is not
included explicitly. In such a case, the -rpath-link option specifies
the first set of directories to search. The -rpath-link option can
specify a sequence of directory names, either by specifying a list of
names separated by colons, or by appearing multiple times.
If the required shared library is not found, the linker will issue a
warning and continue with the link.
If I could make this work, it would seem to be the most desirable way to build 3.5 binaries since the DEP issue is fixed in the 5.2 version of gcc 3.3. Also, it seems critical in general to be able to build to a backwards-compatible set of shared libraries. For one thing, it is easy to get into a situation where libraries have conflicting dependencies (like libc.so.3.5 and libc.so.5.2) unless you build every binary and library from source on each platform--which seems unnecessary and more painful than shared libraries are worth.
Using inductive reasoning, it appears likely that Microsoft is going to increment the version number of the libraries they ship to match the version of Interix so that you would have *.so.3.5, *.so.5.2, *.so.6.0 and then maybe *.so.6.1 in the mix shortly (Vista is NT 6.0, therefore Interix 6.0; will Longhorn Server be NT 6.1?).
gcc -L/usr/local/lib -L/usr/local/ssl/lib -Wl,-rpath-link=/usr/lib:/usr/local/li
b:/usr/X11/lib -Wl,-soname,libc.so.3.5 -Wl,-soname,libSM.so.3.5 -Wl,-soname,libI
CE.so.3.5 -Wl,-soname,libXext.so.3.5 -Wl,-soname,libX11.so.3.5 -o aterm command.
o graphics.o grkelot.o main.o menubar.o misc.o netdisp.o rmemset.o screen.o scr
ollbar.o utmp.o xdefaults.o pixmap.o thai.o -L/usr/X11R6/lib -lSM -lICE
-lX11 -lXext
/opt/gcc.3.3/lib/gcc-lib/i586-pc-interix3/3.3/../../../../i586-pc-interix3/bin/l
d: cannot open libc.so.3.5: No such file or directory
collect2: ld returned 1 exit status
*** Error code 1
Stop.
< Message edited by breiter -- Mar. 29, '06, 10:38:58 AM >
|
|
|
|
|
RE: cross compiling from Interix 5.2 to 3.5 - Apr. 12, '06, 4:14:31 PM
|
|
|
breiter
Posts: 343
Joined: Jun. 14, '04,
From: Washington, DC
Status: offline
|
Well, I'm starting to think that static builds are the way to go. Correct me if I'm wrong but a statically linked binary built on 32-bit x86 Interix 5.2 will run on Interix 3.5. Further it will thunk and work on x64 Interix 5.2 and also be forward compatible with Interix 6 x86/x64. Is that right?
The main downside is that when you link against something that gets a security patch like zlib or OpenSSL, you have to recompile the whole thing and release a new package. Also the binaries are bigger than they need to be, but dependency hell is solved.
|
|
|
|
 New Messages |
 No New Messages |
 Hot Topic w/ New Messages |
 Hot Topic w/o New Messages |
|
 Locked w/ New Messages |
 Locked w/o New Messages |
|
 Post New Thread
Reply to Message
Post New Poll
Submit Vote
Delete My Own Post
Delete My Own Thread
Rate Posts |
|
|
|
Printable Version
)
. Just to clarify, I can't get anything SUA (ie. 5.2) to run reliably on a dual Xeon, 64-bit or otherwise.