can you compile for OSX with GCC on a Linux box?

zozo
Posted:
in General Discussion edited January 2014
We are going to be porting some small pieces of code (like DLLs) that are written in C.



What are my options? Just use GCC on a Linux/Windows machine? SSH into my Mac and use my GCC (is that even possible?) or should I lend the engineers my iBook and let em use that?



I'm totally programming ignorant (as you can probably tell), so any options and advice are welcome.

Comments

  • Reply 1 of 15
    As far as I know, there are still some Apple-specific modifications to GCC that don't exist in the main branch. SSHing would probably be easiest and safest, and besides, you have to run the code to debug it.

    Hm, with that in mind it may be better if you lend them your iBook
  • Reply 2 of 15
    toweltowel Posts: 1,479member
    I'm a little confused. Binaries compiled on Linux will generally not run under OSX. You need to compile in OSX. But if your goal is to run these binaries on OSX, then why not transfer the source to the iBook, either locally or remotely (ftp/ssh) and compile on the iBook? But if you're developing for OSX your engineers should really have an OSX box to test on... But if you're not porting to OSX then why bother with the iBook? Why am I so confused?
  • Reply 3 of 15
    Quote:

    Originally posted by Towel

    I'm a little confused. Binaries compiled on Linux will generally not run under OSX. You need to compile in OSX. But if your goal is to run these binaries on OSX, then why not transfer the source to the iBook, either locally or remotely (ftp/ssh) and compile on the iBook? But if you're developing for OSX your engineers should really have an OSX box to test on... But if you're not porting to OSX then why bother with the iBook? Why am I so confused?



    It sounds like he needs to port some backends to OSX... (the DLL comment). Tell us what you are going to do, and how it works out for you...



    Using GCC on my linux box gives me the option to cross-compile but I have let to try it.
  • Reply 4 of 15
    Quote:

    Originally posted by \\/\\/ickes

    It sounds like he needs to port some backends to OSX... (the DLL comment).



    a DLL, or Dynamically Linked Library, is just another name for a Shared Library (as most *nix systems call it, with a .so extension; MacOSX/Darwin being the oddball and instead changing the extension to .dylib).



    Quote:

    Originally posted by Towel

    I'm a little confused. Binaries compiled on Linux will generally not run under OSX. You need to compile in OSX. But if your goal is to run these binaries on OSX, then why not transfer the source to the iBook, either locally or remotely (ftp/ssh) and compile on the iBook? But if you're developing for OSX your engineers should really have an OSX box to test on... But if you're not porting to OSX then why bother with the iBook? Why am I so confused?



    you forget one thing though: "cross compilers". gcc can run on X machine, and make code for Y machine. ie, with a special version of gcc, i can build linux-ix86 programs on a netbsd-ppc machine. and, by the by, while cross compiling is cool (in its geekiness), it can be a very difficult thing to setup. i consider myself a pretty good programmer, and i tried for a few days, to no avail, setting up a cross-compiler that ran on linux-ppc and built for linux-arm. Your developers may have more luck (and I'm sure its a bit easier making a cross compiler from two popular distros, like linux-ix86->darwin-ppc), but time should be a consideration. If you're lucky, you can find someone else who already built the cross compiler, and get its installer from them.



    Theres a few more things to note. First, if the code is solid, and its just a matter of feeling out any mac-platform issues, then you better get those developers access to a mac. Even if they have a cross compiler, they are going to want to run the progam. But, if they are strongly confident in their code and its cross-platform-ness, they can build and test it locally (without using a cross compiler), then cross-compile it for osx, trusting in their ignorany bliss that the mac version won't have any platform issues. If they are good programmers in the first place, there shouldn't be any real platform issues. I make sure all my code is platform neutral, and haven't had issues throwing it on different computers and recompiling in a long time. Cross compiling is one option, ssh (or some other telnet-like app) is another, and of course giving them the computer is another option.



    Quote:

    Originally posted by dfryer

    As far as I know, there are still some Apple-specific modifications to GCC that don't exist in the main branch.



    Yes, apple does have some modifications, but under the rules of the GNU General Public License (which gcc is distributed under), they had to distribute those changes in source form to the world. So, if those mods are absolutely necessary to the development, then they can get them from apple (free subscription is required, i believe). But, from what I understand, the project started out as a non-mac program, and therefore probably didn't take advantage of apple's mods.
  • Reply 5 of 15
    dfryerdfryer Posts: 140member
    ThuhFreak:



    Quote:

    Yes, apple does have some modifications, but under the rules of the GNU General Public License (which gcc is distributed under), they had to distribute those changes in source form to the world. So, if those mods are absolutely necessary to the development, then they can get them from apple (free subscription is required, i believe). But, from what I understand, the project started out as a non-mac program, and therefore probably didn't take advantage of apple's mods.



    Their modifications are available as the source to the apple version of gcc; whether that compiles on linux or not I don't know (although it shouldn't be too difficult)



    Still, can standard gcc produce mach-o binaries? Or is that an Apple-specific thing? I'd be more concerned about the linking than the compiling into object code myself.



    If it is possible, it's also important to make sure the right compiler version is used, due to changes in the way gcc handles C++.
  • Reply 6 of 15
    zozo Posts: 3,117member
    i'll try n explain as best as I can from a non programmer view.



    Background: we have a Java application that "controls" some hardware. This hardware is DVB satellite modems from manufacturers like www.hauupauge.co.uk www.technisat.com www.technotrend.com etc.



    In order to "control" these hardware modems (usb), we created a (guess) "controller". This controller is written in C. Each hardware box has a DLL that the controller uses to control the hardware. These DLLs are also written in C. From what I understand, there isnt that much in the DLLs, pretty basic stuff... but still, made for Windows.



    Our engineers work mostly in Linux.



    So anyway, while the bulk of the software is a Java app, in order for it to "talk and control" with the hardware we have to prot the DLLs to OSX (and maybe Linux while we're at it).



    The manufacturers will have to make the actual drivers to have the boxes work in OSX... but thats their "problem". Actually, they've been really slow with the driver bits. There are opensource drivers for Linux, but no one has started to port for OSX. Damn them. www.linuxtv.org is the palce to go in case you're interested.



    Well, I dont know if what I just mentioned clears anything up... or means nothing at all. Sorry.



    If anyone can give a hand or give some pointers for OSX porting, please let me know. Probably easy stuff for you guys. I'd put you in touch with a couple of our programmers.
  • Reply 7 of 15
    dfryerdfryer Posts: 140member
    The impression that I get from what you're saying is that the code that they need to port is possibly quite platform specific. If that's the case, then having the developers work with macs directly would probably be a lot more productive.



    Apple's developer web page is where I'd start- they would have information on writing and talking to drivers and other Apple-specific voodoo that might need to have.



    Do I understand you correctly that a) these DLLs (one per model of hardware supported) need to be ported AND

    b) Drivers for each model of hardware supported need to be ported? Or are the DLLs themselves the drivers?
  • Reply 8 of 15
    zozo Posts: 3,117member
    yes and yes.



    Quote:

    b) Drivers for each model of hardware supported need to be ported? Or are the DLLs themselves the drivers?



    Drivers are separate.. the DLLs are like mini drivers. (no, not the actress)



    For the time being we are starting with a new Ethernet based satellite modem. It works , but everything has to be setup manually. The Java application is a sort of aggregator. Click a button and it sets the proxies, dials default dialup connection, and voila', you send commands via dialup, but receive them via satellite at high speed.



    Click another button and you get a satellite TV listing (MPEG 4 channels). Click another button and you get the listing of all the multicasted/broadcasted files (apps, movies, etc etc).



    So. While the Java aggregator is java and SHOULD be easy to port, we need to port the controllers as well. With the case of the Etehrnet modem, we will make it control the box directly... no drivers needed.



    In windows, you install the USB/PCI drivers, then install our software. Our software sets the correct transponder settings, makes the hardware "listen" correctly, changes things on the fly, etc. Its pretty spiffy sh!t actually.



    If you want some basic info about the service you can check out www.eutelsat.net



    Again... any help is most appreciated
  • Reply 9 of 15
    If I get this right ...



    Sounds like firstly you need to develop a JNI (Java Native Interface) library for the Java configuration app to talk to the underlying hardware drivers. That should be pretty straightforward as JNI is a cross platform technology. Go to http://developer.apple.com and type 'JNI' into the search field at the top of the page for documentation on how to do that on OSX.



    Porting the hardware drivers might be more complex though. OSX's driver model is pretty different to most *nix's so how much code will be shared is difficult to say - possibly not much...



    I would definitely recommend developing the software on a Mac though - quite apart from the technical details of cross-compiling, etc you get the 'feel' of the platform better ;-)



    Hope that helps.
  • Reply 10 of 15
    I would assume that JNI is what they *are* already using on the windows side- it's just that the underlying C (the "controller") which JNI is being used to invoke also needs to be ported (aside from the drivers, which is another issue).



    What would be helpful would probably be documentation on a) interfacing with drivers and b) access to OS X networking settings (since that seems to be the relevant area)
  • Reply 11 of 15
    Quote:

    Originally posted by dfryer

    I would assume that JNI is what they *are* already using on the windows side- it's just that the underlying C (the "controller") which JNI is being used to invoke also needs to be ported (aside from the drivers, which is another issue).



    Yes, I'm imagining something like this:



    (1) Java Config App -> (2) JNI library -> (3) Driver A, Driver B, etc



    1) Should be as portable as Java ever is.

    2) Might only need a recompile on OSX although I suspect that loading (3) will need some slightly different code. Some tips on JNI here http://developer.apple.com/documenta...section_4.html

    3) Is the interesting bit and might have to be re-implemented using the IOKit if it's talking directly to hardware.



    Quote:

    What would be helpful would probably be documentation on a) interfacing with drivers and b) access to OS X networking settings (since that seems to be the relevant area)



    Good jumping off point for OSX networking is here http://developer.apple.com/networking/. Most stuff using plain sockets should 'just work'.



    Networking configuration on OSX is acheived through the System Configuration framework which is powerful but can be a bit hairy to program to. http://developer.apple.com/documenta...erview926.html
  • Reply 12 of 15
    zozo Posts: 3,117member
    just to recap... talked to an engineer who basically confirmed that our "Controller" and the associated DLLs are mini-drivers that do some basic I/O managment.



    we indeed do have an SDK that is normally given to the hardware manufacturer's so they can ensure that their products are compatible with our software and service. But I guess the SDK is to make it work with Windows?
  • Reply 13 of 15
    Quote:

    Originally posted by ZO

    we indeed do have an SDK that is normally given to the hardware manufacturer's so they can ensure that their products are compatible with our software and service. But I guess the SDK is to make it work with Windows?



    Probably. But in the case of the Ethernet based modem it might be just a list of commands that your controller sends to the modem across a standard socket connection and the expected responses. In fact, you might even find that it's talking plain http e.g. http://<modem ip address>/control.cgi?getchannels returns an html page with a list of channels (or whatever)... Then if you download the rendezvous source and get it running on the modem you don't even need to know it's IP address
  • Reply 14 of 15
    zozo Posts: 3,117member
    cool idea about Rendezvous... I'll see what the locals think about it. I'm pretty sure they'll just say/think "bah, sales guy trying to tell us whats best for us uber geeks"



    ah well... heres to trying...
  • Reply 15 of 15
    The source code is very portable (compiles for Mac, Windows & Unix) so there's no need for it to be an OS X-only feature, if that helps. It's probably exactly the same stuff they use for playlist sharing on iTunes for Windows.
Sign In or Register to comment.